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ABSTRACT 



A method is provided for managing a computer network 
includes the step of providing respective router configura- 
tion information in executable form; producing respective 
Structured Router Objects (SROs) that are respectively 
associated with respective router configuration information 
and that respectively organize associated information in 
executable form in respective structures in electronic 
memory; and producing respective Single Protocol Topol- 
ogy (SPT} objects in electronic memory, each respectively 
associated with a different respective single protocol and 
each respectively interrelating SROs associated with the 
same respective single protocol. 
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POINTED TO BY PNTR UNDER 
"AREAAR" 



FIG. 18-2 



CREATE A NEW GROUP 
"BORDER_AREAAREA-" 
AND UNDER THIS GROUP 
ADD POINTER TO ROUTER 
AND TO ROUTE POINTED 
TO BY PNTR 
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SET PNTR TO NEXT 
POINTER IN CONN 



1 



c 




START 
~~T— 



SET PNTR TO FIRST 
POINTER IN CONN 



NOTES: 

INPUT TO THIS PROCESS IS: CONN.AR 

(AN IP CONNECTION) 
OUTPUT IS: AREASET 
(SET OF OSPF AREAS WITH WHICH 
ROUTER PORTS ON CONN ARE 
ASSOCIATED) 



DOES 
ROUTER 
ASSOCIATED HAVE 
.OSPF CONFIGURED, 
? 

YES 



LET OSPF_OBJ REFER 
TO OSPF OBJECT ASSOCIATED 
WITH OSPF CONFIGURED ON 
ROUTER ASSOCIATED WITH PNTR 



10j_ 



LET NETSTMT BE NEXT 
NETWORK STATEMENT IN 
OSPFOBJ 



DOES 
OSPF.OBJ 
HAVE ANY NETWORK 

STATEMENTS 
? 

YES 



YES 



NETSTMT LAST" 

NETWORK 
STATEMENT IN 
OSPF_OBJ 
? 



LET NETSTMT BE FIRST 
NETWORK STATEMENT IN 
OSPFOBJ 



NET.ADDR IN SRO OR NETWORK 
STATEMENT IN CONFIG FILE 



NO 



11- 



FIG. 19 



DOES 
ADDRESS ON 
PNTR MATCH NETWORK 
STATEMENT 
? 



ADD AREA MENTIONED IN 
NETSTMT TO AREASET IF 
IT IS NOT ALREADY THERE 
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( START ) 
°1 4 



SET AREA_SET TO EMPTY 



c 



EXIT 



> 



NO. 



2 



1- 

DOES 
ROUTER HAVE 
X>SPF CONFIGURED. 
? 

(yes 



LET OSPF.OBJ REFER TO OSPF 
OBJECT ASSOCIATED WITH OSPF 
CONFIGURED ON ROUTER 
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YES 

IS" 

PA LAST IP 
PORT ADDRESS 
OF ROUTER 
? 

"no 



DOES' 
OSPF_OBJ 
HAVE ANY 
NETWORK 

.STATEMENTS. 
? 

'yes 



LET PA BE NEXT 
IP PORT ADDRESS 
OF ROUTER 



LET PA BE FIRST IP PORT 
ADDRESS OF ROUTER 



5-x 



LET NETSTMT BE NEXT 
NETWORK STATEMENT 
IN OSPFOBJ 



1 



LET NETSTMT BE FIRST 
NETWORK STATEMENT 
IN OSPF OBJ 



YES. 



1NO 

NETSTMT LASr 
.NETWORK STATEMENT. 
IN OSPF.OBJ, 
? 




ADD AREA MENTIONED 
IN NETSTMT TO AREASET 



FIG. 20 
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OBJECT TYPE: MPT 

MPCS (MULTIPROTOCOL CONXN'S) 



-) . < 


DBJECT TYPE: MPCIN] 


OBJECT TYPE: MPCfll 


SUBNET: [1] 


SUBNET: [1] 


SUBNET: [N] 


SUBNET: [N] 


POINTERS • 


POINTERS • 







POINTER 






RT.PO 


POINTER 


RT.PO 








POINTER 






RT.PO 


POINTER 


RT.PO 





RT= 


ROUTER NAME 


PO= 


PORT 



FIG. 21 
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C 



1- 
1a- 

2- 



START 



3 



SET OUTPUT (MPT) TO EMPTY 



I 



SET MISMATCH TO EMPTY 
I 



SET C TO FIRST CONNECTION 
IN SPT| P 



5 



ADD TO MPT A MPC 
CORRESPONDING TO C 



NOTE: INPUTS 
TO THIS PROCESS 
ARE SPT|p 
AND SPT lPX 
OUTPUTS ARE: MPT 
& MISMATCH SET 



IS 

C THE LAST 
IP CONNECTION 
IN SPT lp 

Tyes 



SET C TO NEXT • 
CONNECTION IN SPT )P 



J 



SET CTO 1ST IPX 
CONNECTION IN SPT !PX 



COMPLETELY NO MATCH 
OR SUBSET RELATIONSHIP. 

10 2 



ADD TO MPT A MPC 
CORRESPONDING TO C 



WHAT 
IS THE RESULT 
OF MATCHING C WITH 
MPC IN THE MPT. 
? 

'mismatch 



COMPLETE 
MATCH 



ADDC.SUBNETTO 
THE MATCHING MPC 



ADD SPT INFO TO 
MISMATCH SET 



"1 



£ 



SET CTO NEXT 
IPX CONNECTION 




FIG. 22 
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NOTE: INPUT TO 
THIS PROCESS 

IS THE MPT. 

CIS AN IPX 
CONNECTION 



7a- 



SET MPNTR TO THE NEXT 
MPCINMPT 



C START 

1 



SET MPNTR TO THE FIRST 
MPC OF INPUT MPT 




FIG. 23 
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OBJECT TYPE: MPT 



MPCS: [EMPTY] 



FIG. 24A 



NOTE: INPUTS TO THIS PROCESS 
ARE:SPT, P ANDSPT| PX 



1- 



OUTPUT MPT SET 
TO EMPTY 



OBJECT TYPE: MPT 



MPCS: 



[OBJECTfYPE: MPglf 

("SUBNET: tD.30.OJ5 ~ 



! POINTER i 



R1.E0 



FIG. 24B 



OBJECT TYPE: MPT 



MPCS: 



OBJECT TYPE: MPCH1 



SUBNET: 10.30.0.0 



POINTER 



R1.E0 



-A 

I 

I 



la- 



ser MISMATCH SET 
TO EMPTY 



SET C TO 1 ST CONNECTION 
IN SPT|p 



FIRST IP MPC ADDED 
TO OUTPUT MPT 



LOOPING THROUGH STEPS 
3,4,5 ANOTHER IP MPC 
IS ADDED TO THE MPT 



[OBJECT TYPE: MPCf21 



SUBNET: 10.10.0.0 



X 



, .POINTER! 

r--—T.-±~± r } 1 



! POINTER 



R1.S0 v 



R2.S0 i 



FIG.24C 
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STILL LOOPING THROUGH STEPS 
3,4,5 THE LAST IP MPC IS ADDED 
TO THE MPT 



OBJECT TYPE: MPCBl 



SUBNET: 10.20.0.0 



! OBJECT TYPE: MPCJ31 



OBJECT TYPE: MPCH1 SUBNET: 10.10.0.0 



SUBNET: 10.30.0.0 



POINTER 
R1.E0 




rPOINTER] 



R2.E0 | 



FIG.24D 
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OBJECT TYPE: MPCH1 



SUBNET: 10.30.0.0 



! S UBNE T: 9C 



POINTER 



R1.E0 



CIS SET TO 9C 



RESULT IS COMPLETE MATCH 



FINDING THE FIRST IPX CONNECTION 
AND A COMPLETE MATCH ON SUBNET, 
THE FIRST IPX MPC IS ADDED TO THE MPT 



OBJECT TYPE; MPCF31 



OBJECT TYPE: MPCJ21 
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POINTER 
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NO, C NOT LAST IPX CONNECTION 



CIS SET TO 7A 



RESULT IS COMPLETE MATCH 
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ADDED TO THE MPT 
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SUBNET: 7A 



POINTER 
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POINTER 




R2.E0 



FIG.24G 
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NO, C NOT LAST IPX CONNECTION 
C IS SET TO 98 
RESULT IS COMPLETE MATCH 



THE LASTIPX MPC IS ADDED TO THE MPT 



OBJECT TYPE; MPCffl SUBNET: 10.20.0.0 



OBJECT TYPE: MPCM1 



SUBNET: 10.10.0.0 




OBJECT TYPE: MPCKl 



SUBNET: 98 



SUBNET: 10.30.0.0 



SUBNET: 7A 



SUBNET: 9C 



POINTER 
R1.E0 



POINTER 
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FIG. 24H 
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THE LAST IPX CONNECTION HAS 
BEEN ADDED TO TH E MPT, NOW 
EXIT THE PROCESS 



OBJECT TYPE: MPCf31 



OBJECT TYPE MPCE1 
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OBJECT TYPE: MPCM1 
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SUBNET: 98 
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POINTER 
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POINTER 
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MPT 




OBJECT TYPE: ROUTER(SRO) 



HOSTNAME: R1 



PORTS 



PORT[1]E0 



MEDIA TYPE: ETHERNET 



NUMBER: 0 



ENCAPSULATION: ARP 



BANDWIDTH: 10000 



DELAY: 100 



PORT ADDRESSES 



PORT_ADDR[1](R1,E0,IP1) 



PORT [2] SO 



MEDIA TYPE: SERIAL 



NUMBER: 0 



ENCAPSULATION: HDLC 



BANDWIDTH: 1544 



DELAY: 2000 



PORT ADDRESSES 



PROTOCOL: IP 



ADDR: 10.30.7.2 255.255.0.0 



PORT_ADDR [2] (R1,S0,IP1) 



PROTOCOL: IP 



ADDR: 10.10.4.1 255.255.0.0 



PORTJ\DDR|1](R1,E0,IPX1) 



PROTOCOL: IPX 



ADDR:9C 



PORT_ADDR[2](R1,S0,IPX1) 
PROTOCOL: IPX 



ADDR: 7A 



FIG. 25-1 
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OBJECTTYPE: ROUTER(SRO) 



HOSTNAME: R2 



PORTS 




PORT [1] SO 



MEDIA TYPE: SERIAL 



NUMBER: 0 



ENCAPSULATION: HDLC 



BANDWIDTH: 1544 



DELAY: 2000 



PORT ADDRESSES 
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PORT [2] EO 



MEDIA TYPE: ETHERNET 



NUMBER: 0 



ENCAPSULATION: ARP 



BANDWIDTH: 10000 



DELAY: 100 



PORT ADDRESSES 



PORT_ADDR [1](R2,S0,IP1) 
PROTOCOL: IP 



ADDR: 10.10.4.2 255.255.0.0 



I 



PORT_ADDR [2] (R2.E0.IP1) 



PROTOCOL IP 



ADDR: 10.20.5.2 255.255.0.0 



PORT_ADDR [1](R2,S0,IPX1) 
PROTOCOL: IPX 



ADDR: 7A 
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PORT_ADDR [2] (R2,E0,IPX1) 
PROTOCOL: IPX 



ADDR: 98 



FIG. 25-2 
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IP: 10.10.10.1 255.255.255.0 

IPX;7A IP: 10.10.10.2 255.255.255.0 





PX:7A 


R1 


) — 



TO IPX: 7A 



T1 IP: 10.10.10.3 255.255.255.0 



IP CONN 



OBJECT TYPE: CONN ni 



SUBNET: 10.10.10.0 



POINTERS 




POINTER 
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POINTER 



POINTER 
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SUBNET: 7A 



POINTERS 




POINTER 



POINTER 



POINTER 




FIG. 26 
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C 



START 



4 1 



SET C TO FIRST MPC IN MPT 



SET C TO NEXT MPC 




YES 
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EXIT 



J 



YES 



DOES 
C HAVE ALL THE 
POINTERS ASSOCIATED 
WITH PORTS THAT HAVE 
IN IP-UNNUMBERED PORT> 
ADDRESS 
? 



YES 



NOTE 

INPUTS: MPT & SRO'S 
OUTPOSTS: UPDATED MPT & 
SRO'S 



ADD SUBNET "IP-UNNUMBERED" TO 
THE MPC IN MPT REFERRED TO IN C 



FIG. 27 
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ROUTED NETWORK USING IP-UNNUMBERED AND ALSO IPX INTERFACES 



RING 



ROUTER 


SO 




SO 


ROUTER 
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ROUTER 


SO 
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ROUTER 
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ROUTER R3: 



ROUTER R4: 



VERSION 10.0 

! 

HOSTNAME R3 

j 

NOVELL ROUTING 0000.0C08.94DD 

! 

INTERFACE LOOPBACK 1 
IPADDRESS 122.33.2.1 255.255.0.0 

INTERFACE SERIALO 
IP-UNNUMBERED LOOPBACK 1 

IPX NETWORK 8B 

! 

INTERFACE FDDI 0 

IPADDRESS 20.20.1.1 255.255.0.0 

END 



VERSION 10.0 

! 

HOSTNAME R4 
I 

NOVELL ROUTING 0000.OC04.3A3E 

i 

INTERFACE LOOPBACK 1 
IPADDRESS 127.38.7.6 255.255.0.0 

INTERFACE SERIALO 

IP-UNNUMBERED LOOPBACK 1 

IPX NETWORK 9C 
! 

INTERFACE FDDI 0 

IPADDRESS 20.20.0.0 255.255.0.0 

END 



FIG. 29A 



FIG. 29B 



ROUTER R5: 



ROUTER R6: 



VERSION 10.0 

! 

HOSTNAME R5 

! 

NOVELL ROUTING 0000.0D09.A5EE 

! 

INTERFACE LOOPBACK 1 
IPADDRESS 127.38.7.6 255.255.0.0 

INTERFACE SERIALO 
IP-UNNUMBERED LOOPBACK 1 
IPX NETWORK 8B 

! 

END 



FIG.29C 



VERSION 10.0 

! 

HOSTNAME R6 

! 

NOVELL ROUTING 0000.OD05.4B4F 
! 

INTERFACE LOOPBACK 1 
IPADDRESS 132.43.12.11 255.255.0.0 

INTERFACE SERIALO 
IP-UNNUMBERED LOOPBACK 1 
IPX NETWORK 9C 

l 

END 
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OBJECT TYPE: ROUTER 

HOSTNAME: R5 
PORTS ♦ 




PORT [1]: L1 



MEDIA TYPE: LOOPBACK 



NUMBER: 1 



ENCAPSULATION: NONE . 



BANDWIDTH: 1 



DELAY: 5 



PORT ADDRESSES 



PORT [2]: SO 



MEDIATYPE: SERIAL 



NUMBER: 0 



ENCAPSULATION: HDLC 



BANDWIDTH: 1544 



DELAY: 2000 



PORT ADDRESSES 



PORT_ADDR f1l(R5,L1,IP1) 



PROTOCOL: IP 



ADDRESS: 126.37.6.5 255.255.0.0 



PROTOCOL IP 




PORT_ADDR[1](R5,S0,IP1) 



ADDRESS: 



X 



PORT_ADDR[1](R5,S0,IPX1) 



PROTOCOL IPX 



ADDRESS: 8B 



OBJECT TYPE: UNNUMBERED 



REF: L1 



STATIC ROUTES: EMPTY 



FIG. 30C 
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OBJECT TYPE: ROUTER 



HOSTNAME: R6 



PORTS 



PORT[1]:L1 




MEDIA TYPE: LOOPBACK 



NUMBER: 1 



ENCAPSULATION: NONE 



BANDWIDTH: 1 



DELAY: 5 



PORT ADDRESSES 



PORT [2]: SO 



MEDIA TYPE: SERIAL 



NUMBER: 0 



ENCAPSULATION: HDLC 



BANDWIDTH: 1544 



DELAY: 2000 



PORT ADDRESSES 



PORT_ADDRfn(R6,L1,IP1) 



PROTOCOL: IP 



ADDRESS: 128.39.8.7 255.255.0.0 




PORT_ADDR[1](R6,S0,IP1) 



PROTOCOL: IP 



ADDRESS: 
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PORT_ADDR [1] (R6.S0.IPX1) 



PROTOCOL: IPX 



ADDRESS: 9C 



OBJECT TYPE: UNNUMBERED 



REF: L1 



STATIC ROUTES: EMPTY 



FIG.30D 
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OBJECT TYPE: SPT 

PROTOCOL: IP 
CONNS • 



OBJECT TYPE: CQNN[1] 

SUBNET: 20.20.0.0 
POINTERS • 
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POINTER 




R4.F1.IP1 


POINTER 


R3.F1.IP1 





OBJECT TYPE: SPT 

PROTOCOL: IPX 
CONNS • 




OBJECT TYPE: CONN[1] 

SUBNET: 8B 



POINTERS 



OBJECT TYPE: CONN[2] 

SUBNET: 9C 



POINTERS 
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POINTER 
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POINTER 
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POINTER 
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POINTER 
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FIG. 30E 
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MPT 




OBJECT TYPE: MPC 131 



OBJECT TYPE: MPC f21 



SUBNET: 20.20.0.0 




OBJECT TYPE: MPC Ml 



SUBNET: IP-UNNUMBERED 



SUBNET: 8B 



SUBNET: IP-UNNUMBERED 



SUBNET: 9C 





FIG.30F 



04/21/2003, EAST Version: 1.03.0002 



U.S. Patent May 21, 2002 Sheet 50 of 103 US 6,393,486 Bl 
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START 



2 I 

INITIALIZE THE OUTPUT SPT P TO EMPTY 



S 
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INITIALIZE PA TO THE FIRST PORT 
ADDRESS OF PROTOCOL P IN THE 
LIST OF ROUTERS 



EACH DISTINCT (SUB)NET 
ISADDEDTOTHE SPTAS 
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ADD SUBNET P (PA)TOSPTp 



SET PA=NEXT PORT 
ADDRESS OF TYPE £ 
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i!^/SUBNETp(PA)^§i. 



INSPTc 
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ADD POINTER TO PA UNDER 
THE CONNECTION IN SPT 
MATCHING SUBNETp(PA) 



SET FRM TO THE SET OF FRAME-RELAY 
MAPS ASSOCIATED WITH PA'S PORT 

* 



SET FRM_MEMBERTO THE FIRST 
ELEMENT OF FRM 



CONNSET=CONNS MATCHING SUBNET 
(PA) IN SPTp WITH A POINTER EXACTLY 
MATCHING FRM MEMBER 



YES 




NO 



IS 

THERE A \ Y ES 
'MEMBER OF CONNSET 
HAVING JUST ONE 
POINTER 

9 



NOTE: 
ORIGINAL SPT 
BUILD FLOW 

MULTI-POINT 
WAN EXTENSIONS 



ADD POINTER TO PA TO 
THIS MEMBER HAVING JUST 
ONE POINTER 



FIG. 32-1 
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NEXT ELEMENT OF FRM 
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ADD SUBNET(PA) TO 
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POINTER TO PA 



ADD SUBNET p (PA)TO SPTp 
& UNDER THIS, POINTERS TO BOTH 

PA AND TO PORT ADDRESS 
CORRESPONDING TO FRM_MEMBER 
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FIG. 34 



NOTE TO FIGURE 34 

THE NOTION OF A FRAME 
RELAY CLOUD IMPLIES FULLY 
MESHED CONNECTIVITY, YET 
IN ACTUALITY CONNECTIVITY 
MAY BE LIMITED AS SHOWN 
WITH DOTTED LINES INSIDE 
CLOUD 
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OBJECT TYPE: ROUTER 




HOSTNAME: R1 


PORTS • 








PORT [1]: SO 




MEDIA TYPE: SERIAL 


NUMBER 0 


ENCAP: FRAME RELAY 


BANDWIDTH: 1544 


DELAY: DEFAULT 


PORT ADDRESSES: 


\ 


! PORT_ADDR[1](R1,S0,IP1) 


! PROTOCOL: IP 


I ADDRESS: 117.33.4.1 255.255.0.0 



FRAME MAPS • 




PROTOCOL IP PROTOCOL: IP PROTOCOL: IP 



ADDR: 117.33.4.2 ADDR: 117.33.4.3 ADDR: 117.33.4.4 

DLCI: 100 DLCI: 101 DLCI: 102 

BROADCAST: YES BROADCAST: YES BROADCAST: YES 
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VERSION 10.0 

! 

HOSTNAME R1 

! 

IP SUBNET-ZERO 

! 

INTERFACE SERIALO 

DESCRIPTION SERIAL 0 

ENCAPSULATION FRAME-RELAY 

IPADDRESS 117.33.4.1 255.255.0.0 

FRAME RELAY MAP IP 117.33.4.2 100 BROADCAST 

FRAME RELAY MAP IP 117.33.4.3 101 BROADCAST 

FRAME RELAY MAP IP 117.33.4.4 102 BROADCAST 

! 

ROUTER RIP 109 
NETWORK 117.33.0.0 
END 



FIG. 38A 



VERSION 10.0 
! 

HOSTNAME R2 

i 

IP SUBNET-ZERO 
! 

3^1 INTERFACE SERIALO 
DESCRIPTION SERIALO 
ENCAPSULATION FRAME-RELAY 
IPADDRESS 117.33.4.1 255.255.0.0 
FRAME RELAY MAP IP 117.33.4.1 100 BROADCAST 
FRAME RELAY MAP IP 117.33.4.3 101 BROADCAST 
! 

ROUTER RIP 109 
NETWORK 117.33.0.0 
END 
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VERSION 10.0 
! 

HOSTNAME R3 

! 

IP SUBNET-ZERO 

! 

INTERFACE SERIALO 

DESCRIPTION SERIALO 

ENCAPSULATION FRAME-RELAY 

IP ADDRESS 117.33.4.1 255.255.0.0 

FRAME RELAY MAP IP 117.33.4.1 100 BROADCAST 

FRAME RELAY MAP IP 117.33.4.2 101 BROADCAST 

! 

ROUTER RIP 109 
NETWORK 117.33.0.0 
END 



FIG. 38C 



VERSION 10.0 
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HOSTNAME R4 

! 

IP SUBNET-ZERO 
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description serialo 

encapsulation frame-relay 

i pad dress 117.33.4.1 255.255.0.0 

frame relay map ip 117.33.4.1 100 broadcast 

! 

ROUTER RIP 109 
NETWORK 117.33.0.0 
END 



FIG. 38D 



04/21/2003, EAST Version: 1.03.0002 



U.S. Patent 



May 21, 2002 Sheet 61 of 103 US 6,393,486 Bl 



OBJECT TYPE: SPT 



PROTOCOL: IP 



CONNS: [EMPTY 



PA = 117.33.4.1 255.255.255.0 



Li 



NO - SUBNETp(PA) NOT IN SPTp 



1 



1 



INITIALIZED SPT SET 
TO EMPTY 



2 
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PROTOCOL: IP 
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POINTERS: 
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NO - PA NOT LAST PORT ADDRESS 

V J 
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YES: 117.33.4.1 BELONGS TO SUBNET 117.33.4.0] 
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POINTER 
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POINTER 
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NO: NOT LAST MEMBER OF FRM 



FRM_MEMBER = 117.33.4.2 (R2.S0JP1) 
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POINTER 
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POINTER 
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c 



START 





1-) 






SET VIOLATION LIST TO EMPTY 












SET ST TO THE FIRST STATIC 
ROUTE (IN THE SET OF ROUTERS) 


SET ST TO NEXT 






STATIC ROUTE 







YES, 



c 



NO 

is s 

ST THE 
LAST STATIC 
ROUTE 
? 



EXIT 



NOTE: 
INPUT: SPTp&SRO'S 
OUTPUT: VIOLATION SET 



IS 

THERE A 
ROUTER WITH AN^ 
YES^X IP PORT ADDRESS WHICH* 
MATCHES ST. 

JEXT_HOP_ADDF 
? 

W 



ADD ST (ANNOTATED WITH THE 
ROUTER IT IS CONTAINED IN) 
TO THE VIOLATION LIST 
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NOTE: 
INPUT: LIST OF SRO'S 
OUTPUT: VIOLATION LIST 



SET R TO THE 
NEXT SRO 



SETACC TO NEXT 
ACCESS LIST IN R 




ADD ACEL AND MORE 
I GENERAL ELEMENTS 
BEFORE ACEL TO 
VIOLATION LIST 



SET ACEL TO 
NEXT ELEMENT 
INACC 
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INPUTS: SPTp AND THE SRO'S IT 
POINTS TO, AND THE OPERATIONAL 
STATUS FOR EACH ROUTER, ROUTER 
PORT AND CONNECTION 
OUTPUTS: ROUTING TABLES FOR 
PROTOCOLp FOR EACH ROUTER 



c 



'J. 



START 



FOR EACH ROUTER (IN THE SET OF SRO'S) INITIALIZE ITS 
ROUTING TABLE (FOR PROTOCOL P) TO EMPTY 



, ■ FOR EACH ROUTER THAT HAS OPERATIONAL STATUS, . 
PUT IN A ROUTING TABLE ELEMENT FOR EACH OF ITS 
PORT ADDRESSES (FOR PROTOCOL P) AND STATIC 
ROUTES ASSOCIATED WITH PORTS IN OPERATIONAL STATUS 



FOR EACH OPERATIONAL ROUTER, RO, FOR EACH OF RO'S PORTS PO, THAT 
IS OPERATIONAL AND FOR EACH OF RO'S ROUTING PROTOCOLS (FOR P) AN 
UPDATE MESSAGE WILL BE DELIVERED TO THE CONNECTION ASSOCIATED 
WITH PO IF IT IS NOT EMPTY; THE UPDATE MESSAGE WILL CONSIST OF 
{RT_EL L RT_EL= SEND(RT_EL_IN_TABLE, RP,<RO,PO> WHERE RT_EL_IN_TABLE 
IS A ROUTING TABLE ELEMENT IN RO'S ROUTING TABLE} 



FOR EACH CONNECTION (IN SPT P ) THAT RECEIVES AN UPDATE MESSAGE 
FROM ROUTER RO, PORT PO, IF IT IS OPERATIONAL, THEN THE UPDATE 
WILL BE PASSED TO ALL THE ROUTER PORTS IT IS POINTING TO EXCEPT 
FOR RO, PO: IF THE CONNECTION IS NOT OPERATIONAL ALL UPDATE 
MESSAGES ARE DROPPED 



I 



FOR EACH OPERATIONAL ROUTER RO AND EACH UPDATE UPD THAT IT 
RECEIVES THROUGH PORT PO, IF PO IS OPERATIONAL, THE SET UPD TO_PROC 
WILL BE FORMED;IF PO IS NOT OPERATIONAL, UPD IS DROPPED; UPD_TO_PROC 
IS DEFINED AS THE SET: {RT_ELLRT_EL=RECEIVE(RT_EL_UPD,RP,<RO l PO>) 
WHERE RT_EL_UPD IS A MEMBER OF UPD, AND RT.EL'S DESTINATION IS NOT 
IN RO'S ROUTING TABLE, OR IF IT IS THEN IT EITHER HAS A BETTER COST/ADMIN 
DISTANCE OR AN EQUAL COST/ADMIN DISTANCE, BUT NOT AN EXACT MATCH} 



<S> 



FIG. 43-1 
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±> I 

FOR EACH UPD_T0_PR0CTHAT ROUTER RO FORMS, ADD EACH OF ITS 
MEMBERS TO RO'S ROUTING TABLE, REMOVING ANY ELEMENTS ALREADY IN 
TABLE WITH MATCHING DESTINATIONS, BUT HIGHER COST/ADMIN DISTANCE 



FOR EACH UPD_TO_PROC SET, REMOVE ANY ELEMENT IF IT HAD MATCHED THE 
DESTINATION AND COST/ADMIN DISTANCE OF AN ELEMENT ALREADY IN 

THE TABLE 



FOR EACH UPD_TO_PROC SET FORMED BY ROUTER RO, FOR EACH ROUTING 
PROTOCOL RP_XTHAT RO IS RUNNING, AND EACH OPERATIONAL PORT PO, 
SEND OUT THE FOLLOWING UPDATE SET TO THE CONNECTION THAT POINTS 
TO RO, PO: {RT_EL_OUT L RT_EL_OUT= SEND(RT_EL_UPD, RP_X, <RO,PO> 
WHERE RT_EL_UPD BELONGS TO UPD_TO_PROC} 
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h i 

FOR EACH OPERATIONAL ROUTER, RO, FOR EACH OF RO'S PORTS PO, THAT 
IS OPERATIONAL AND FOR EACH OF RO'S ROUTING PROTOCOLS (FOR P) AN 
UPDATE MESSAGE WILL BE DELIVERED TO THE CONNECTION ASSOCIATED 
WITH PO IF IT IS NOT EMPTY; THE UPDATE MESSAGE WILL CONSIST OF 

{RT_EL L RT_EL= SEND(RT_EL_IN_TABLE, RP,<RO,PO> WHERE 
RT_EL_IN_TABLE IS A ROUTING TABLE ELEMENT IN RO'S ROUTING TABLE} 

' I 



ADD TO EACH UPDATE MESSAGE ATAG OF 
THE ROUTER JUST VISITED 






FOR EACH UPD TO PROC SET, REMOVE ANY ELEMENT IF IT HAD 
MATCHED THE DESTINATION AND COST/ADMIN DISTANCE OF AN 
ELEMENT ALREADY IN THE TABLE 




* 




FOR EACH ROUTER RO, REMOVE ANY UPD TO PROC SET THAT WAS 
FORMED FROM AN UPDATE HAVING ATAG MATCHING RO 


8~ 


1 



FOR EACH UPD_TO_PR0C SET FORMED BY ROUTER RO, FOR EACH ROUTING 
PROTOCOL RP_X THAT RO IS RUNNING, AND EACH OPERATIONAL PORT PO, 

SEND OUT THE FOLLOWING UPDATE SET TO THE CONNECTION THAT POINTS 
TO RO, PO: {RT_EL_OUT L RT_EL_OUT = SEND(RT_EL_UPD, RP_X, <RO,PO> 
WHERE RT_EL_UPD BELONGS TO UPD_TO_PROC} 
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t 

FIG.43B 



04/21/2003, EAST Version: 1.03.0002 



U.S. Patent May 21, 2002 Sheet 73 of 103 



US 6,393,486 Bl 



LU 
_f 








00 












tr 








o 




o 




RES 




ROUT 


Q_ 


LAST 1 


• 


PE: 


_i 


OF 


CO 




O 




1— 




O 


i 






O 




LU 


O 




LU 




LU 






LU 


3 


PR 


CD 


LU 


o 
















1 






LU 






1— 






2! 
LU 












LU 






I 

LU 






LU 






_J 




• 


rAB 


ION 


HS 








o 








•2: 






h- 




ZD 


CO 






LU 


o 




a 


o 









LU 






1— 












LU 






LU 






1 

LU 






LU 
_l 




• 


CO 








o 


CO 

□z 


o 


fee 


& 








p 




1— 


ZD 


CO 


CO 


o 


LU 


o 




Q 


o 









CM 






1 

LU 


















LU 












LU 






_l 
LU 






LU 
_J 




• 


GQ 
£ 


ION 


CO 


O 








§ 








1— 


i— 




=5 


CO 


co 


o 


LU 


O 


en 


Q 


O 





LU 










o 














6d 










LU 

i — 


z 




NDIS 


CE: 


POIN' 


CON 






Q_ 


CE 


TOCI 


T/AC 


IRFA 


0H1 


IRFA 


PRO 


COS 


INTE 


NEX 


INTE 





a 




cd 


















LU 
i — 


z 




NDIS 


LU 

o 


.NIOd 


CON 


o 




CL 


LU 

O 


TOCI 


T/AC 


:rfa 


0H1 


.RFA 


PRO' 


COS 


INTE 


NEX 


INTE 











LU 

o 
























CO 






Q 






z: 




o 




lii 
o 


TOO 


T/AC 


;rfa 


\PR0 


COS 


INTE 



5 

0 





LU 










o 










z 




aL 




u 
o 


IMINDISTA 


CE: 


HOPPOINTE 


CECONN: 


PROTOC! 








COST/ 


INTER 


NEXT 1 


INTER 



r 



CM 



04/21/2003, EAST Version: 1.03.0002 



U.S. Patent May 21, 2002 Sheet 74 of 103 US 6,393,486 Bl 



CONN [1] 



CONN [4] 



SA 
(SOURCE 
ADDRESS) 



DA1 

(DESTINATION!— 
ADDRESS) 



EO 



R1 



CONN [2] 
SO SO 



R3 



EO 



EO 



R2 



CONN [3] 
SO SO 



R5 



R4 



E0__ 



DA3 
(DESTINATION 
ADDRESS) 



DA2 

—j (DESTINATION 
ADDRESS) 



DATA LABELS U SEP I N 
CPS DISCUSSION 

SC SOURCE CONNECTION 

DC DESTINATION CONNECTION 

SA SOURCE ADDRESS 

DA DESTINATION ADDRESS 

CPS COMPLETED PATH SET 

APS ACTIVE PATH SET 

SPT SINGLE PROTOCOL TOPOLOGY 

CR CURRENT ROUTER 

NC NEW CONNECTION 

EL ROUTING TABLE ELEMENT 

P PROTOCOL 

CPO COSTPATH OBJECT 



DEFINITION: COMPLETED PATH SET- CPS 

THE SET HAVING: NO ELEMENTS; 1 ELEMENT; OR, MORE THAN 1 ELEMENT 

NO ELEMENTS MEANS: NO RATH FROM SATO DA 
ONE (1) ELEMENT MEANS: ONE PATH FROM SATO DA 
MORE THAN ONE ELEMENT: MULTIPLE PATHS FROM SATO DA 

THE CPS FOR SA TO DA2 LOOKS LIKE: 
P;CONN{1|;R1;C0NN[2];R3;CONN(4J;DA2] 



THE CPS FOR SATO DAI LOOKS UKE: 



THE CPS FOR SA TO DA3 LOOKS UKE: 
J} 

FIG. 45 
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( 



START 



) 



1 i 




INITIALIZE THE SET OF COMPLETED 
PATHS (CPS) TO EMPTY 




f 


INITIALIZE RLPS 
TO EMPTY 




NOTE: 

SAAND DA ON SAME 
SUBNET, THUS THERE IS 
ONE PATH, WHICH IS 
FROM SATHROUGH 
SUBNET/CONN SC TO DAI 



INITIALIZE SC TO THE CONNECTION IN 
SPTp MATCHING SA'S SUBNET 



I 



INITIALIZE DC TO THE CONNECTION IN 
SPTp MATCHING DA'S SUBNET 




FIG. 46A 
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c 



FROM 



) 



FROM 13 
FIGURE 46C 



INITIALIZE THE ACT 
TO{[SA;SC;[R1]],... 
EACH ROUTER F 
POINTE 


VE PATH SET (APS) 
[SA;SC;[RN]} FOR 
ij INDEXED BY A 
RINSC 







11 




YES 



EXIT 



J 



SET CURRENT PATH (CP) TO A PATH IN 
APS & SET APS ASIDE 



10j_ 



SET CURRENT ROUTER (CR) TO THE 
LAST ROUTER IN THE PATH CP 



ADDCPSTORLPS 
(THE SET OF ROUTING 
LOOP PATHS) 




REF: FIG.56 



FOR EXAMPLE: 
IN THE CPS: 
[SA;SC;R1; 

CONN2;R5]THE 
CURRENT 

ROUTER (CR) IS 
SET TO R5. 



SET COST PATH OBJECTS (CPO'S) TO 
THE SET OF CONNECTIONS/NEXT 
ROUTER PAIRS ASSOCIATED WITH 
ROUTING TABLE ELEMENTS THAT 
MATCH DA IN CRROUTINGTABLEp 



c 



TO 
FIG. 46C 

FIG.46B 



04/21/2003, EAST Version: 1.03.0002 



U.S. Patent May 21, 2002 Sheet 77 of 103 US 6,393,486 
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FROM 
FIG. 46B 



-K13V 



G> 



YES 



THERE WAS NO ROUTE IN 
CR THAT MATCHES DA. 
GOTO 8 FIGURE 46B 




NO 



SET EL TO A MEMBER OF CPO 



15 2 



SET EL ASIDE /EMPTY CPO 



REF: FIG.57 



ADD [CP; 
EL.CONN;DATOCPS 




17 1 



NO 



ADD [CP;ELCONN; ELNEXTROUTER] 
TO APS 



NOTE: EL IS A ROUTE 
POINTING TO AN INTERFACE 
ON A SUBNET THAT DA IS 
DIRECTLY CONNECTED TO 



FIG. 46C 
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INPUTS: RT- ROUTING TABLE & DA - DESTINATION ADDRESS 
OUTPUTS: CPO - SET OF COST PATH OBJECTS ON MATCHING ELEMENT 
(EMPTY IF NO-MATCH) 



( EXIT: CPO= EMPTY ) 




SET EL TO ELEMENT IN RT 
BELONGING TO DA'S MAJOR 
NET AND HAVING THE MOST 
SPECIFIC MASK 



EXIT: 

CPO= GATEWAY OF 
LAST RESORT COST PATHS, 




EXIT: 

CPO= EL.COSTPATH 



?1 



I.E., HAS LEAST 
SPECIFIC MASK 



SET EL TO ELEMENT IN RT 
BELONGING TO DA'S MAJOR 
NET HAVING NEXT MOST 
SPECIFIC MASK THAN IT 
JUST HAD 



IS 

EL THE LEAST" 
SPECIFIC MEMBER OF 
RT HAVING DA'S MAJOR 
NET 
?^ 

YES 



GO TO 2 



FIG. 47 
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ROUTER 

(RD 

OBJECT TYPE: ROUTING TABLE 

PROTOCOL: IP 

GATEWAY OF LAST RESORT: EMPTY 
ELEMENTS • 



ROUTING TABLE ELEMENT EL[1] 
DESTINATiON: 10.10.0 0 255.255.0.0 
COST PATHS * 

I 

PROTOCOL: DIRECT CONNECT 
COST/ADMINDISTANCE: [0/0] 

INTERFACE: EO 

NEXT HOP POINTER: 

INTERFACE CONN: CONN [1] ~ 



ROUTING TABLE ELEMENT EL[2] 

DESTINATION: 199.28.77.0 255.255.255.0 

COST PATHS - 

I 

PROTOCOL: DIRECT CONNECT 
COST/ADMINDISTANCE: [0/0] 

INTERFACE: SO 

NEXT HOP POINTER: 

INTERFACE CONN: CONN [2] 



ROUTING TABLE ELEMENT EL[3] 



DESTINATION: 199.28.80.0 255.255.255.0 



COST PATHS 



PROTOCOL DIRECT RIP 



COST/ADMINDISTANCE: [1/120] 



INTERFACE: S1 



NEXT HOP POINTER: 



INTERFACE CONN: CONN [5] 



ROUTING TABLE ELEMENT EL[4] 



DESTINATION: 20.20.0.0 255.255.0.0 



COST PATHS 



PROTOCOL RIP 



COST/ADMINDISTANCE: [1/120] 



INTERFACE: SO 



NEXT HOP POINTER: [R3,SQ,IP1] 



INTERFACE CONN: CONN [2] 



FIG. SO 



PROTOCOL: RIP 



COST/ADMINDISTANCE: [1/1201 
INTERFACE: S1 



NEXT HOP POINTER [R4.S1.IP1] 
INTERFACE CONN: CONN [5] ~ 
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OBJECT TYPE: ROUTING TABLE 



PROTOCOL IP 



GATEWAY OF LAST RESORT: EMPTY 
ELEMENTS • 




ROUTING TABLE ELEMENT EL[2] 



ROUTING TABLE ELEMENT EL[1] 



DESTINATION: 20.20.0.0 255.255.0.0 



COST PATHS • 

I" 

I PROTOCOL: RIP 



COST/ADMINDISTANCE: [1/120) 



INTERFACE: SO 



NEXT HOP POINTER: [R4,E0,IP1] 
INTERFACE CONN: CONN [3] 



DESTINATION: 199.28.77.0 255.255.255.0 

COST PATHS » 

I ~ 
PROTOCOL: DIRECT CONNECT 

COST/ADMINDISTANCE: [0/0] 

INTERFACE: E0 

NEXT HOP POINTER [R1.E0.tP11 
INTERFACE CONN: CONN [1] 



ROUTING TABLE ELEMENT EL[3] 






DESTINATION: 10.10.0.0 255.0.0.0 


ROUTING TABLE ELEMENT EL[4] 


COST PATHS • 


DESTINATION: 199.28.80.0 255.255.255.0 








COST PATHS • 




PROTOCOL: DIRECT CONNECT 














COST/ADMINDISTANCE: [0/0] 






PROTOCOL: RIP 






INTERFACE: E0 






COST/ADMINDISTANCE: [1/120] 






NEXT HOP POINTER: 






INTERFACE: EO 






INTERFACE CONN: CONN [1] 






NEXT HOP POINTER [R2.E0.IP1] 












INTERFACE CONN: CONN [1] 





FIG. 51 



04/21/2003, EAST Version: 1.03.0002 



U.S. Patent 



May 21, 2002 Sheet 83 of 103 US 6,393,486 Bl 



ROUTER | 
(R3) 



OBJECT TYPE: ROUTING TABLE 



PROTOCOL IP 



GATEWAY OF LAST RESORT: EMPTY 
ELEMENTS 




ROUTING TABLE ELEMENT EL[1] 
DESTINATION: 10.10.0.0 255.255.0.0 



COST PATHS • 

I 

I PROTOCOL: RIP 



COST/ADMINDISTANCE: [0/1] 
INTERFACE: SO 



NEXT HOP POINTER [R1.E0.IP1] 
INTERFACE CONN: CONN [2] 



ROUTING TABLE ELEMENT EL[2] 

DESTINATION: 199.28.78.0 255.255.255.0 
COST PATHS • 

I 

PROTOCOL: DIRECT CONNECT 

COST/ADMINDISTANCE: [0/0] 

INTERFACE: E0 

NEXT HOP POINTER: [R4,S0,IPn 
INTERFACE CONN: CONN [4] 



ROUTING TABLE ELEMENT EL[3] 
DESTINATION: 20.20.0.0 255.0.0.0 

COST PATHS * 

l 

PROTOCOL: DIRECT CONNECT 
COST/ADMINDISTANCE: [0/0] 

INTERFACE: E0 

NEXT HOP POINTER: 

INTERFACE CONN: CONN [4] 



FIG. 52 
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ROUTER 
(R4) 



OBJECT TYPE: ROUTING TABLE 



PROTOCOL: IP 



GATEWAY OF LAST RESORT: EMPTY 



ELEMENTS 



ROUTING TABLE ELEMENT EL[1] 



DESTINATION: 10.10.0.0 255.255.0.0 



COST PATHS 



I 



PROTOCOL: RIP 



COST/ADMINDISTANCE: [0/1] 
INTERFACE: SO 



NEXT HOP POINTER: [R1.E0.IP1] 
INTERFACE CONN: CONN [2] 



ROUTING TABLE ELEMENT EL[2] 



DESTINATION: 199.28.80.0 255.255.255.0 
COST PATHS • 



PROTOCOL: RIP 



COST/ADMINDISTANCE: [1/120] 
INTERFACE: S1 



NEXT HOP POINTER: [R4.S1.IP1] 
INTERFACE CONN: CONN [5] 



ROUTING TABLE ELEMENT EL[3] 
DESTINATION: 20.20.0.0 255.255.255.0 

COST PATHS - 

I 

PROTOCOL: DIRECT CONNECT 
COST/ADMINDISTANCE: [0/0] 

INTERFACE: E0 

NEXT HOP POINTER: 

INTERFACE CONN: CONN [4] 



FIG.52A 
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13 1 



CPO IS EMPTY, 
GO TO STEP 8 



8 X 



APS IS NOT EMPTY 



9,10 j_ 



CP = [SA;CONNm; 
R1;CONN[5](R4j) 



12 



1 



;CR = R4) 



AT STEP 12, COST PATH OBJECTS ARE SET TO THE CONNECTIONS/NEXT 
ROUTER PAIRS FOUND IN THE ROUTING TABLE ELEMENTS ASSOCIATED 
WITH THE DESTINATION ADDRESS 



U,15j_ 



EL IS SETTO A MEMBER 
OF THE COST PATH 
OBJECTS (CPO'S) 
CPO SET TO EMPTY 



16 



?. 





PROTOCOL: DIRECT CONNECT 




— ► 


COST/ADMINDISTANCE: [0/0] 






INTERFACE: E0 






NEXT_HOP_POINTER: 






INTERFACE.CONN: CONN \A] 





CR= l 
ROUTER 
. R4 J 



DEST. CONN (DC) = CONN[4] 
ELCONN = CONN [4]: 
YES CONDITION 



18^ 

r 



ADD 



|SA;CONN[1];R1;CONN[5];R4;CONN[4];DA] 
10 CPS (WHERE CP =[SA;CONN[1];R1;CONN[5];R4])| 



FI6.53E 
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OBJECT TYPE: ACCESS LIST 

NUMBER 

ELEMENTS ♦ 



ELEMENT [1] 




ACTION: 


ADDRESS: 


MASK: 


ELEMENT [N] 




ACTION: 


ADDRESS; 


MASK: 



FIG. 54 
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INPUTS: 

ADDRESS (ADDR BEING CHECKED) 
& ACCL (ACCESS LIST BEING MATCHED 
AGAINST) 



( START ) 



°2 



1 1 




SET-EL TO FIRST ELEMENT OF ACCL 


SET EL TO NEXT 
ELEMENT IN ACCL 






r 


1 




FIG. 55 
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C 



STARTING AFTER 11 
IN FIGURE 46B 



SET IN PORT TO THE PORT ON 
CR POINTED TO BY THE 
CONNECTION IN CP 
PRECEEDING CR 




FIG. 56 
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NOTE: THIS CHART 
INTEGRATES WITH 
FIG. 46C 



c 



STARTING AFTER 15 
IN FIGURE 46C 



3 



SETOUTPORTTO PORT ON 
CR POINTED TO BY ELCONN 




FIG. 57 
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NOTE: THIS CHART 
INTEGRATES WITH 
FIG. 46B 



c 



EXIT TO: 11 



c 



STARTING AFTER 10 
IN FIGURE 46B 






YES 




r 


PUT [CP:DA] IN CPS 




r 


( EXIT TO: 8 ) 



FIG. 58 
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START 







INITIALIZE THE CPS TO EMPTY 


h 


i 


INITIALIZE THE RLPSTO EMPTY 







( EX,T > 



IS 

THERE A 
NO^tONNECTION IN SPT P 
MATCHING DA'S 
SUBNET 
? 



D 



2 



YES 



INITIALIZE DC TO THE 
CONNECTION IN SPTp MATCHING 
DA'S SUBNET 



1 



SET APS TO {[R]} 



EXIT: TO STEP 9 
FIG. 46B 



FIG. 59 
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R2 



R3 



R1 

LOOPBACKADDR 
50.7,8.3 





R4 






R6 

LOOPBACKADDR 
30.50.2.1 



FIG. 60 



ROUTER Ri: 

VERSION 10.0 

! 
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SYSTEM AND METHOD USING LEVEL These are just a few of the numerous factors that combine to 

THREE PROTOCOL INFORMATION FOR define the environment in which network management takes 

NETWORK CENTRIC PROBLEM ANALYSIS place. Some of the more routine objectives of a typical 

AND TOPOLOGY CONSTRUCTION OF network manager include the swift analysis of large volumes 

ACTUAL OR PLANNED ROUTED 5 of data, troubleshooting problems in a timely fashion, and 

NETWORK implementing changes or upgrades without disruption of 

normal network operations. 

CROSS-REFERENCE TO RELATED Numerous network management tools are available to aid 

APPLICATION m achieving network management objectives. For example, 

t, . . . • P i- c kt no/^<o <ic\ fli^ 10 there are tools that monitor network traffic and tools that 
This is a division of application Ser. No. 08/668,639 filed . 4 , r . , rt „ n v , . « 
t ^ + I. j j i- • *■ ** monitor management information base (MIB) data. Con- 
on Jun. 21, 1996, now abandoned, which is a continuation- - . & t4 . , i * * -i *l * 
f \. o vt ao Mfv^oi ci j t -»<-> figuration management tools can produce audit trails that 
ln-part of application Ser. No. 08/493,984 filed on Jun. 23, . ~. A . , . * _ , , r ^ , - 
^rJCr l j * .« t . ' . r , mdicate the history of changes to routing device configura- 
1995, now abandoned, the entire contents of which are ^ *_ i . * *i_ r 
... , ,, f r ii -r c ii tions. There are network management stations that can 
hereby incorporated by reference for all purposes as it fully ie „ 4 . , *• *. i u j 
t f rth herein collect mformatioo from network probes and present a 

network manager with data representing the state of the 

BACKGROUND OF THE INVENTION network. Simulation tools can predict the performance and 

behavior of hypothetical networks. Topology rendering tools 

1. Field of the Invention can be used to identify possible problems on particular 

The invention relates in general to computer networks, 20 network components as well as network-wide problems, 

and more particularly, to the design, modification and man- There are particularly difficult technical challenges in the 

agement of computer networks. realm of network management tools that identify possible 

2 Description of the Related Art network-wide problems and that render network topologies. 

Computer networks comprise multiple computers that are 25 For exam P le > * ™ n d{m ™ 1 } to ^errmne the logical con- 

intercoLcted for communicaUon with each other. A net- nectlODS b ^ ccn TTJa* ^^J"*"™* a ^ 

work may include only a few computers physically located operational network Addmonally, the problems associated 

close together or it may include many computers dispersed ™ th P r ° vidl f a netwo * c V1 ™ ° f * T °^ mS 

over a wide area. A network may include subnetworks or ™ a n f^°* T , Slgmfica f y tha ° ^ pr ° bl f f 5 

, , . i /¥akt\ -a 4 i i • i , associated with testing an individual network component for 

local area networks (LANs). A network also may include , n . , . , j- * . i_i 

. , , , j . • . . . . , potential problems. Moreover, diagnosing routing table 

widely separated computers interconnected over a wide area r , t * . . ?. . „ 4 -t ..j. 

* i muw\ r» , • . , problems may involve complex inquiries aimed at ldentify- 

network (WAN). Routing devices, in essence, are special- f J identifvin dead end aths for 

ized computer networking devices that route or guide pack- m ^ routm g °°P S m 1 en i*y m g ea en P a s > or 

* r j- j ■ # *• *u u * ♦ i tv • it example. Furthermore, secunty issues involving router 
ets of digitized information throughout a network. Typically, a™** , j s 
when a host computer sends a packet out onto a network, it 35 access ^ can ^ difficult to diagnose without a relatively 
includes in the packet address information that specifies the comprehensive understanding of the operation of the net- 
source of the packet, the sending host, and the intended work containing routers with such access lists, so that, for 
destination of the packet, another host computer connected mUa "*> a route a blocked host can ^ tracked * 
to the network. The sending and receiving hosts ordinarily Thas » there has been a need for improved network man- 
are interconnected through routing devices which use packet ^ agement tools that can provide network centric analysis of 
address information to route packets through the network potential problems and that can provide diverse views of 
from one routing device to the next en route from the network topology in order to enhance a network manager's 
sending host to the receiving host. Routing devices, abilit y to manage a network. The present invention meets 
therefore, perform a complex and critical role in network ^is need. 

operations. 45 BRIEF DESCRIPTION OF THE DRAWINGS 

In many environments, networks are subjected to almost mQ 1 a flow ^ of ^ Qvcra]1 ^ ^ ^ 

continual changes as host computers are added or deleted, ^ Qf ^ t invention 

for example. Unfortunately, networks are susceptible to „~ . . . . , L „ 

failure. In today's information based economy, network ™?- la ^ the subprocess of populatmg the Struc- 

failure can have severe implications to organizations that 50 ^ R ° UtCr ° bjeCtS the 6x51 P mcesS 0CCUmng Wltlun nG - 
rely upon computer networks as a primary conduit for 

information. Network management is the process of main- FIG - shows the subprocess of Constructing the Topol- 

taining the integrity of a network. It involves functions such °gy 35 would logically follow the process described in FIG. 

as, observing the state of a network, monitoring network la m the of the invention by a user, 

traffic, troubleshooting the network, making changes to the ss FIG. lc shows the subprocess of Creating the View 

network and ensuring that the changes have the desired Objects, a process that would typically follow the process 

effect. Network management has become increasingly shown in FIG. lb. 

important as the size, diversity arid importance of computer FIG. Id shows the subprocess of applying non-routing 

networks have grown. The rise in prominence of the internet table checks another portion of the invention that occurs 

underscores the importance of high quality network man- 60 after the process in FIG. lb is executed, 

agement. FIG. le shows the subprocess of Importing Auxiliary live 

Complex technical challenges are an inherent feature of information (such as routing tables) which is an alternative 

the network management function. For instance, network to constructing routing tables (FIG. 1/). The user selects 

components may be diverse and physically dispersed. Many which of these procedures to use. 

different communication protocols may be used simulta- 65 FIG. If shows the subprocess of calculating routing 

neously over the network. Security issues play a role in tables, which is an alternative process to the procedure 

communications between hosts connected to the network. shown as FIG. le as described above. 
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FIG. lg shows the subprocess of Applying routing table FIG. 8i shows the completed SPT object following FIG. 

integrity checks which is the procedure executed following 4, Step 7. 

either FIG. lc or FIG. 1/ as described above. FIG. Sj shows the SPT that would be created by the 

FIG. lh shows the subprocess of the user making changes process shown in FIG. 4 for the case where Protocol-IPX. 

to the SRO given rendered logical topologies from FIG. lb, 5 $\q 9 shows an extension of the flowchart in FIG. 4, 

rendered abstract topologies from FIG. lc, and integrity which constructs the SPTs, to check for the integrity 

checks from FIGS. Id and If. violation of duplicate addresses. 

FIG. li shows the subprocess of importing modified piG. 10 is a flowchart to check for the integrity violation 

SROs back into the live network, this occurs logically after G f overlapping subnet masks given an SPT as input, 

the user is satisfied with the network configuration as 1 piG. 11 is a topology drawing of a hypothetical network 

captured by the set of SROs currently in the database. &howQ ^ ft Campus ^ h suppofts discussion of the 

FIG. Ix shows a block diagram of a network comprising "Create Views" process shown as FIG. lc. 

routers (Ro) and a workstation that can access the network, FIG. 12 shows the object data structure of a Campus View 

and, on which the processes in FIGS. la-It can run. w 0bject corrcsponding t0 the topology shown in FIG. 11. 

FIG. 2 shows the object data structure of the "Structured fig. 13 is a flowchart of the process that forms a Campus 

Router Object (SRO) a principle data structures of the yiew Qbjectj • Q ^ spT and SROs ^ { t 

invention. A set of SROs serve as the primary input for all \ . . 

, 4 , • FIG. 14 is a topology drawing of the same network shown 

subsequent analysis. . „ r ^i?t- • fi L £ 

^ _ , . . in FIG. 11 representing an OSPF view of the same coohgu- 

F1G. 3 shows the object data structure of the Single 20 ration showQ ^ a Campus view (fef mQ 14) 

Protocol Topology" object, a principle data structures of the . . nonp . r „ . t , t t 

»uT- 1 ♦ j • tU *L -..iti^ ti» PIG. 15 is the OSPF View Object data structure corre- 

invention that is populated in the process shown as FIG. lo. , . , . ™~ u '' 

It will serve as input to numerous processes as shown in FIG. ^ponding to the topology shown in FIG. 14. . 

1 FIGS. 16a & b shows the SRO object data structures for 

. . „ , r 4 , ... . c- the routers shown in FIG. 14. 

FIG. 4 is a flowchart of the process that creates a Single 25 

Protocol Topology (SPT) object data structure for a given FIG. 17 shows the SPT object data structure for the 

protocol P given the set of SROs (FIG. 3) as input. network shown in FIG. 14. 

FIG. 5 is an annotated topology drawing of a hypothetical FIG. 18 is a flowchart of the process that forms an OSPF 

network. It is referenced by subsequent figures. View <*J«* dala structure given an SPT and set of SROs as 

FIG. 6a & b are sample router configuration files for input, 

routers in FIG. 5. FIG. 19 is a flowchart expanding on the "AreaSet" 

FIG. la shows the populated SRO associated with the C0Qce P t in FIG. 18 

router configuration file shown in FIG. 6a, Router 1 (Rl) in FIG. 20 is a flowchart expanding on the "How Many 

PIG, 5. 3S Areas Does Router Have" question from FIG. 18. 

FIG. lb shows the populated SRO associated with the FIG. 21 shows the object data structure of the Multiple 

router configuration file shown in FIG. 6b, Router 2 (R2) in Protocol Topology (MPT) object, a principle data structure 

PIG 5 of the invention that is populated during execution of the 

FIG. 8 is a step-by-step walk through of a Single Protocol P rooess shown ^ mG lk 

Topology (SPT) object data structure build routine that is « FIG. 22 is a flowchart of the process that populates the 

shown in FIG.4. MPT object data structure taking a set of SPTs (for the 

FIGS. Ha through 8, illustrate the values of the SPT for different V^ocx>\s) as input. 

Protocol-IP following the execution of steps in FIG. 4 as FIG. 23 is a flowchart expanding on the process of Step 

indicated by annotations on FIG. 5. '7* ™ FIG. 22, "matching connections with Multiprotocol 

FIG. 8a shows the SPT following Step 1, initialized to its 45 Connection (MpQ objects". 

EMPTY state FIGS. 24a through 24/ comprise a step-by-step walk- 

FIG. Sb shows the population of the SPT following FIG. °f ^ MuMJtetacal Topology (MPT) object data 

4, Step 5, with the fir« connection (a subnet) added to the buM rouhnc - 11 refers t0 the to P ol °^ shown m 

t - . FIG. 5. 

object. 50 

FIG. 8c shows the population of the SPT following FIG. K FIGS f 24a *T^/^™r w ™ ^ ^ 

4, Step 4 with a Pointer added to the first Port Address. ***** foUowm g the Ste P< s ) m 22 ' 

FIG. 8d shows the population of the SPT following the F1G - 24a shows the MPT ob J ect initialized t0 EMPTY, 

second pass of FIG. 4, Step 5, adding the next connection to FIG. 24* Shows the addition of the first MpC for 

the object data structure. 55 protocoMP following FIG. 22, Step 3. 

FIG. 8e shows the SPT after the second pass of FIG. 4, FIG. 24c Shows the effect of the loop through FIG. 22, 

Step 5, adding the next pointer to the SPT object data Steps 3, 4, & 5 adding another MpC and pointers (again for 

structure. ProtocoMP) to the object. 

FIG. 8/ shows the looping through FIG. 4, Step 4 adding FIG. 24d shows the effect of the same loop now finishing 

the remaining pointer to the second connection. MpC's and pointers for ProtocoMP. 

FIG. 8# shows the third pass through FIG. 4, Step 5 FIG. 24* shows the completed MPT for ProtocoMP as 

adding the third and last connection to the SPT object data would follow FIG. 22, Step 4. 

structure. FIG. 24/shows the addition of the first IPX element of the 

FIG. 8* shows the fourth pass through FIG. 4, Step 4 65 example following execution of FIG. 22, Step 8. 

adding a pointer to SPT that points to the last port address FIG. 24g shows the addition of the second IPX element to 

of the hypothetical network configuration. the MPT object again looping through FIG. 22, Step 8. 
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FIG. 24A shows the addition of the last IPX element to the 
MPT as follows the last pass through FIG. 22, Step 8. 

FIG. 24/ shows the completed MPT object as would occur 
at the time of FIG. 22, Step 11. 

FIG. 25 shows the Object data structures of the SRO & 
MPT to demonstrate the linkages that inter-relate them as 
they would occur following execution of the process shown 
in FIG. 16. 

FIG. 26 shows an annotated network diagram and instan- 
tiated SPT object data structures that demonstrate a violation 
of the integrity check that finds mismatched protocols during 
the building of the MPT. 

FIG. 27 shows a flowchart for the process for resolving 
IP-unnumbered connections using connections of another 
protocol, this process occurs during the topology construc- 
tion phase (FIG. 16). 

FIG. 28 is a topology drawing of a hypothetical network 
that will be referenced along with subsequent figures to 
show how information missing from the IP SPT because of 
the use of IP-unnumbered is filled-in using the IPX SPT 

FIG. 29a-29o* show hypothetical Router Configuration 
Files for routers (R3 through R6) shown in tlG. 28. 

FIG. 30a shows the SRO object for R3 in FIG. 28. 

FIG. 30b shows the SRO object for R4 in FIG. 28. 

FIG. 30c shows the SRO object for R5 in FIG. 28. 

FIG. 30a" shows the SRO object for R6 in FIG. 28. 

FIG. 30e shows examples of the IP and IPX SPT object 
data structures as they would be populated following the 
execution of the SPT build process in FIG. 4 for IP and IPX. 

FIG. 30/ shows an example of the MPT object data 
structure as it would be populated following the execution of 
the process in FIG. 22 taking the SPTs in FIG. 30e as input, 
and refined with the additional process shown as FIG. 27 
that fills-in information missing due to the use of 
IP-unnumbered. 

FIG. 31 is a repetition of FIG. 4 (a flowchart of the process 
that populates the SPT object data structure) annotated for 
integration with a flowchart for handling the Frame Relay 
WAN complication to the SPT build process. 

FIG. 32 is a flowchart that shows the set of extensions to 
FIG. 31 required to handle the Frame Relay WAN compli- 
cation to the SPT build process (FIG. 4). 

FIG. 33 is the merged result of FIGS. 31 & 32 and shows 
the complete set of logic applied by the invention to accu- 
rately populate the SPT despite the complications introduced 
when the process encounters the presence of Frame Relay 
multi-point WAN. 

FIG. 34 is a topology drawing of a hypothetical network. 
It is referenced by subsequent figures in support of the 
illustrations related to the Multipoint WAN-complication 
discussion. 

FIG. 35 shows a SPT object as would be prepared by a 
naive algorithm incorrectly creating pointers for a Frame 
Relay WAN (FIG. 4) without the enhancements shown as 
FIG/ 32. 

FIG. 36 shows an accurate SPT object for FIG. 4 as 
computed by the SPT build algorithm that takes into account 
Multipoint WAN complication as shown in FIG. 33. 

FIG. 37 shows the SRO object for router Rl in FIG. 34 
focusing on the Frame Map objects. 

FIG. S&a-d shows the router configuration files for each 
router illustrated in FIG. 34 (topology to demonstrate the 
Frame Relay multipoint WAN example). 
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FIG. 39a through 39/shows the step-by-step execution of 
the flowchart in FIG. 33 by indicating values of variables 
and instantiations of the SPT as each step of the flowchart is 
executed. This is part of the process occurring in FIG. 16. 
5 FIG. 40 is a flowchart showing the process for determin- 
ing bandwidth and delay mismatches between adjacent 
routers. This is an integrity check that occurs during the 
phase indicated as FIG. Id 

FIG. 41 is a flowchart showing the process for determin- 
10 ing the existence of unresolved static routes as coded in 
router configurations, this is an integrity check that occurs 
during the execution of the phase shown as FIG. Id. 

FIG. 42 is a flowchart of the process for determining 
access list subsumption problems, this is an integrity check 
15 applied during the phase shown as FIG. Id. 

FIG. 43 is a flowchart showing the process for calculating 
routing table elements taking a SPT and SROs as input, it 
occurs during execution of the phase shown as FIG. If. It is 
an alternative method to capturing live routing tables from 
the network as shown in FIG. le. 

20 

FIG. 43a shows the first modification made to the process 
shown in FIG. 44 to efficiently handle loops encountered 
while creating routing tables. % 

FIG. 436 shows a companion modification to that shown 
25 in FIG. 43a that efficiently handles loops encountered while 
creating routing tables. 

FIG. 44 shows the object data structure of the Routing 
Table object. This object is populated during either of the 
processes shown as FIGS, le or /. It becomes input to the 
30 process shown in FIG. Ig which evaluates integrity checks 
that use routing tables as input. 

FIG. 45 is a topology drawing of a hypothetical network 
and a definition of the Current Path Set (CPS) concept. It is 
used to provide background to enhance the readers under- 
35 standing of the concepts explained in FIGS. 46 through 53. 

FIG. 46a, 466 & 46c comprise a flowchart that describes 
the process of finding paths from a Source Address to 
Destination Address, which is used as a subroutine as part of 
the phase shown as FIG. lg. 
40 FIG. 47 is a flowchart of the subprocess of matching 
routing table elements per FIG. 486 Step 12. 

FIG. 48 is a hypothetical network topology map annotated 
with port designations and subnet addresses to be referenced 
in subsequent FIGS. 49 through 53. 
45 FIG. 49 shows a SPT object data structure corresponding 
to the topology shown in FIG. 48. 

FIG. 50 shows pan of a routing table object data structure 
for router Rl in FIG. 48. 

FIG. 51 shows part of a routing table object data structure 
50 for router R2 in FIG. 48. 

FIG. 52 shows part of a routing table object data structure 
for router R3 in FIG. 48. 

FIG. 52a shows part of a routing table object data 
55 structure for router R4 in FIG. 48. 

FIG. 53o-/ shows a step-by-step walk-through of the 
flowchart in FIG. 46a, 6, &c (a flowchart for finding Paths 
between Source Address and Destination Address) using the 
topology illustrated in FIG. 48 as the example's input 
6Q FIG. 54 shows the object data structure of the Access List 
object in attribute form. 

FIG. 55 is a flowchart showing the process of determining 
whether or not an element is blocked by an access list. This 
logic is invoked during the process shown as FIG. lg. 
65 FIG. 56 is a flowchart that shows the modifications to the 
flowchart in FIG. 46 (which determines network 
connectivity) to take into account Input Access Lists. 
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FIG. 57 is a flowchart that shows the modifications to the putting this information into the invention's data base, 

flowchart in FIG. 46 (which determines network rendering different views of the network, applying various 

connectivity) to take into account Output Access lists. integrity checks, using this information to decide if there are 

FIG. 58 is a flowchart of a modification the invention problems needing to be addressed, making corrections if 

applied to the process shown in FIG. 46b to handle paths 5 there are problems, then either downloading these correc- 

addressed to a router ti° ns to me network, or, putting these corrections back in the 

FIG. 59 is a flowchart of a process which is a variant to <! ata base for reiterat ' vc '"^ In ™>°< th * P"** 55 

the process shown in FIG. 46a-c to handle a path starting , ™ r , ta ,. ^P 1 " 1 * network configuration information, 

from a router, instead of a host address. ana ^ e find problems m the network s configuration, 

mrt _ . , , . 10 evaluate that information, proactively validate prospective 

FIG. 60 is a topology rendering showing unplicit RSRB ch ^ eithef download the back ^ 

connections that preface discussion and subsequent figures ^ ^ routed ne(w()rk of reiterate ^ ^ fe based QD tQe 

to show how the inventon evaluates the quality of connec- confi tion ^ the prospective changes applied . 

tivity given instances of level 2 connectivity (i.e., A £ factor h ^ ^ invem £ n ^ valida . 

fflsSm"" SpeafiCally Rem ° S0UfCe 81118 » Hon of a planned network or changes to an existing one. A 

* network manager, therefore, can better design, manage and 

FIG. 61a is a sample router configuration file for Router mo dify routed user and manage a routed network which is 

Rl in FIG. 60. devoid of, or has fewer problems than without the invention. 

FIG. 61b is a sample router configuration file for Router Throughout the following discussion it will be presumed 

R6 in FIG. 60. 20 that line by line coding involved in implementing the 

FIG. 62 shows the SRO excerpts focusing on the RSRB processes and structures disclosed herein is well within the 

attributes for Routers Rl and R6 having configs in FIGS. abilities of one skilled in the art and so is not described 

61a and 61i>. * herein. * 

FIG. 63 shows a flowchart that computes the "RSRB/ Eacn sub-figure (la-1/) in FIG. 1 relates to a discrete 

DLSw remote peers connectivity" integrity check, This is 25 portion of m overall analytical process in accordance with 

part of the phase shown as FIG. Ig. a curr ent implementation of the invention. 

FIG. 64 shows a flowchart that computes the "BGP FIG> i a repr esents the process for capturing information 

remote neighbors connectivity" integrity check. This is part tfxyul eacn 0 f me routers in the live or planned network from 

of the phase shown as FIG. lg. 30 m a format actually used by a given router. Router devices 

FIG. 65 shows a flowchart that computes the "User are well known in the art. They are switching devices at level 

supplied connectivity requirements" integrity check. This is 3 in the OSI model. For Cisco Systems, Inc. products, for 

part of the phase shown as FIG. lg. example, this input is an ASCII text configuration file in a 

FIG. 66 shows a flowchart that computes the "Routing proprietary language (IOS, TM). For Bay Networks Corp. 

Loops" integrity check. This is apart of the phase shown in 3S products, for example, this input is the binary configuration 

FIG. lg. data base provided as output from a commercially available 

computer program such as Site Manager (TM) program, for 

DETAILED DESCRIPTION OF THE example. The process represented in FIG. la parses the input 

PREFERRED EMBODIMENT data fr om configuration file or the MIB, as described above, 

The present invention comprises a novel method and 40 and fiUs-in default information as necessary to populate 

apparatus for network management. The following descrip- object data structure referred to herein as the Structured 

tion is presented to enable any person skilled in the art to Router Object (SRO). 

make and use the invention. Descriptions of specific appli- FIG. lb represents a process of forming a "topology" 

cations are provided only as examples. Various modifica- from the SROs. In the presently preferred embodiment of the 

tions to the preferred embodiment will be readily apparent to 45 invention, there are several types of consirutent components 

those skilled in the art, and the general principles defined of the topology. One type of component comprises is a set 

herein may be applied to other embodiments and applica- of objects called SPTs, for "Single Protocol Topology". An 

tions without departing from the spirit and scope of the SPT is produced for each protocol running on a network, 

invention. Thus, the present invention is not intended to be such as IP, IPX and Appletalk™ . Running multiple protocols 

limited to the embodiment shown, but is to be accorded the 50 in a network has become a common practice in networking, 

widest scope consistent with the principles and features Each SPT indicates for a given protocol which routing 

disclosed herein. device ports are running the given protocol and which ports 

The purpose of the present invention is to assist network are logically connected over the protocol. Another type of 

managers, adrninistrators and/or planners manage routed component comprising the topology is implemented as an 

networks for which they are responsible. "Routed Network" 55 ob J ect referred t0 berein * an MPT, which stands for 

herein means a set of logically connected devices, each of "Multiple Protocol Topology". In the present embodiment, 

which can operate as a switching device at level 3 in the OSI «s one MPT per network. The MPT includes informa- 

model. A presently preferred embodiment of the invention is tion mat indicates how the SPTs relate to each other. For 

architected to operate in connection with any of the follow- example, if a network routes both IP and IPX, both an IP 

ing environments: a five network to manage; proposed 60 SPT and an IPX SPT wil1 be created, and they will be 

network configuration information existing for a planned cross-referenced to each other to form an MPT. 

network to be analyzed; a live network along with configu- The novel MPT can be used, in conjunction with novel 

ration information for a set of planned changes; or, multiple processes in accordance with the invention, to determine 

live networks to be merged. whether network protocols have compatible addressing. 

A high level view of FIG. 1 shows an overall process, in 65 Processes in accordance with the invention can determine 

accordance with a preferred embodiment of the invention, when two topologies have incompatible addressing and can 

for obtaining network information from a variety of sources, identify the source of the conflict, such as the parts and 
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protocols involved in the conflict. More particularly, during 
the process represented by FIG. lb, logical topologies are 
produced for the different protocols that run on a live or 
planned network. These topologies are called SPTs and are 
produced from the SROs. Once SPTs have been constructed 
for the various protocols, they are interrelated with each 
other to form a structure called an MPT. The MPT can be 
used to identify conflicts between protocols represented in 
the different SPTs. The SPTs and the MPT provide valuable 
diagnostic information that can be useful in identifying 
network problems. 

The processes represented by FIG. 16 produce "level 3 
logic" topologies. A level 3 logic topology is defined by the 
OSI model. FIG. lc represents a process which provides 
more abstract or "higher level** views or representations of 
a network. Examples of these more abstract views are OSPF 
and BGP views These more abstract views can be useful to 
a network manager or designer who wishes to observe only 
certain abstractions or views of a network. Modern networks 
are extremely complex creations. Higher level/more abstract 
views enable the persons responsible for maintaining, 
designing or modifying networks to better visualize the 
network they are operating upon by removing from the vi«w 
components that are not relevant to the immediate task at 
hand or grouping devices. 

Using the object model formed in FIG. lb, (i.e., integrated 
SRO/SPTs/NPT), processes represented by FIG. Id deter- 
mine whether there are potential problems in the actual or 
proposed network represented by the object model. The 
conventional approach to trouble-shooting a routed network 
typically involved a user evaluating routers one by one to 
determine whether there are problems with individual rout- 
ers* configurations. A router configuration is a specification 
interpreted by a router's operating system that indicates 
precisely how a router is to process and respond to all types 
of data packets, and how it generates, receives, and pro- 
cesses messages that are sent between itself and other 
routers to construct routing tables. The abstract view pro- 
duced in accordance with the processes of FIG. lb enables 
a more network-centric view which allows a user to visu- 
alize not just problems in a single router, but also problems 
that relate to two or more routers. An important feature of the 
process represented by FIG. Id is the application of numer- 
ous novel integrity checks which can identify problems in 
not just individual routers, but across routers spanning the 
whole network. "Integrity Check" as used herein means the 
result from a procedure that determines whether this a 
critical or potential problem in the network configuration. 

The differences and relationship between the views pro- 
duced according to the processes of FIG. lc and the integrity 
checks represented by FIG. Id are as follows. In the current 
embodiment, high level/abstract views may be used for 
rendering images of various protocol topologies; while 
integrity checks ordinarily represent information in a more 
textural form. A user can employ both views and integrity 
checks to diagnose potential problems with a network. More 
to the point, views set a graphic or visual context for 
interpreting textual reports of integrity check violations. For 
example, an integrity check violation may identify a net- 
work component or components such as a router or a subnet; 
while the view permits a user to visualize where the com- 
ponent or components resides in the network and its relation 
to other network components. 

Referring now to FIG. Ig, there are multiple types of 
intently checks that can be performed given routing tables as 
input. A routing table is a table with rows (elements) indexed 
by level 3 destination addresses and/or level 3 "summary 
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addresses", which refer to ranges of addresses; if a router 
receives a packet that is not filtered on the incoming port, 
(and the packet's destination is not the router itself), it will 
look for a routing table element that matches the packet's 

5 destination. If no match is found, the packet is dropped. If 
there are a number of matches, then the element with the 
narrowest range (i.e., most specific address range) is used. 
The matching element indicates what port to send the packet 
out of and either a next hop router or the fact that the port 

10 is connected to the local area network (LAN) where the 
destination resides. The packet is sent out this output port 
unless there is an output port filter that blocks transmission. 
Routing tables are produced by routers in a network 
exchange information about destinations they could reach. 

15 See, Comer, Douglas E., "Table Driven IP Routing 1 *, Inter- 
networking with TCP/IP, pp. 113-115, Prentice HaU Inc., 
1991. In a network, different host systems may wish to 
exchange information with one another. In order to do so, 
however, there must be a route through the network between 

20 the hosts. The routing tables are used to switch the packets 
"hop-by-hop" through the network. If two hosts wish to 
communicate, but there is no path enabled between them 
then a "no route" situation, which is just one of the routing » 
table integrity checks in accordance with the invention. 

2S Another example of a routing table check is that the routers 
for a particular destination might be involved in what may 
be referred to as a routing loop. In other words, router 1 may 
receive packets destined for host D and transmit the packets 
to Router 2 which then sends these packets to Router 3 

30 which sends these packs back to Router 1 resulting in an 
infinite loop. These are problems a network manager wants 
to avoid. 

There are a number of approaches to gathering the routing 
table information for use in the process of FIG. lg. One 

35 approach represented by FIG. If is to calculate the routing 
tables through simulation using the topology (SRO/SPTs/ 
MPT) as input. This novel calculation process simulates 
behavior of actual routers in an actual network to produce 
the routing tables used in the process represented by FIG. lg. 

40 Alternatively, if the user does not want to simulate routing 
tables, then, in accordance with a process represented by 
FIG. le, the user can poll live routers in a network to get the 
routing table information and to put it into the routing table 
data structure 17 illustrated in generalized form in FIG. 1/. 

45 FIG. 1A is a process largely guided by the user who has 
access to the views, integrity checks and other information 
that are automatically computed according to other process 
represented in FIG. 1. Given this information, the user can 
observe the problems in his or her network, and conse- 

so quently may make modifications to the object model (i.e., 
the topology comprising SRO/SPTs/MPT). Once the user 
makes changes he or she has a number of alternatives. One 
alternative, represented by FIG. li, is to make the changes 
and download those changes directly into a live router 

55 network by providing the information on the SROs to live 
routers in a live network. Another alternative, represented by 
the feedback path that includes the "what if Analysis" 
comment, is to modify the SROs in the object model and 
reiterate through the process steps described above in order 

6o to analyze and trouble-shoot the proposed network changes 
represented in the updated SROs. 

A significant advantage of the invention is that the infor- 
mation in the object model (SROs/SPTs/MPT) can be both 
used for analysis (creating views and running integrity 

65 checks for example) and for actual download to a live 
network. This advantage is achieved in the preferred 
embodiment by storing router configuration (or MIB) infor- 
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mation in executable form in the SROs. The term "execut- and integrity checks, automatically generate executable coo- 
able" as used herein means a state of representation of router figuration files and before implementing those changes to a 
configuration that contains sufficient detail so that it can be live network, check the proposed changes before then auto- 
translated into a form that a router can execute. matically loading the • fully executable files to the live 
Thus, FIG. 1 shows the overall process, in accordance 5 network for both Cisco Systems and Bay Networks prod- 
with a present embodiment of the invention, of obtaining ucts. 

information from a network, putting it into a data base, FIG. 2 depicts the Structured Router Object which, in 

applying different types of integrity checks, rendering dif- accordance with a presently preferred embodiment of the 

ferent views, using this information to determine if there are invention, we will refer to herein as the SRO. The SRO is a 

problems, making corrections, if there are problems, and 10 data structure encoding the contents of a single router's 

either downloading these corrections to the network or configuration that are relevant to a given network analysis at 

putting these corrections back in an object mode data base hand. We refer to this data structure as "structured" to 

for further analysis. Consequently, a user can capture an convey that it is composed of interrelated attributes and to 

existing (live or modelled) network configuration, analyze it, distinguish it from such constructs as a text file containing 

find problems, evaluate the problems, proactively validate 15 a router's configuration which is amorphous rather than 

changes before downloading the changes back into the structured. 

network. An important factor here is that such proactive FIG. 2 illustrates a sufficient subset of the components 

validation permits making validated changes to a routed constituting an SRO to enable one skilled in the art to 

network without impacting operation of a live network: practice the invention. In an actual real-life SRO there are 

changes can be planned and tested before downloading to a 20 many more components. A SRO, as well as other structured 

live network. objects referred to in this disclosure, can be described in the 

As mentioned above, an important factor distinguishing .hierarchical fashion by starting with top level attributes and 

the present implementation of the invention from conven- • then explaining and illustrating how these attributes are 

tional network analysis tools is the use of an object data further decomposed into lower level attributes. In the dis- 

model is both structured and executable the network to be 2 s closure that follows structured objects will be presented in 

automatically analyzed using the processors represented by two different ways: i) in attribute form which is a description 

FIGS. Id, FIG. lc and in FIG. lg. The executable aspect of of an object's interrelated attributes that omits the exact 

the object model means that the model contains sufficient values of the attributes and ii) in instantiated form which is 

detail to enable information contained in SROs to be readily a description of both the attributes and their (exemplary) 

imported into live network routers. 30 exact values. FIG. 2 provides an attribute form description 

The advantages of the invention can be better appreciated, of a SRO. 

for example, by considering the prior network tool called, In the present implementation of the invention, objects are 

CiscoWorks, whose purpose is configuration management. produced using C++ programming language techniques. 

CiscoWorks deals with the uninterperted text files (Cisco's However, other programming languages could be used to 

Configuration Files). CiscoWorks permits the user to load 35 produce the structures. This is considered to be well within 

these files and make textual modifications, but the user still the ordinary level of skill in the art, and, therefore, is not 

is at risk of introducing syntax errors, for instance, since explained in detail herein. 

changes are not validated before the user downloads them to Referring to FIG. 2, at reference numeral 1 there is shown 

the router. In contrast, the processes and structures employed an attribute, which is host name. This is a unique name for 

in the current embodiment of the invention perform auto- 40 identifying the router. Looking down the structure, the next 

mated validation of changes because they use structured high level attribute is Ports. The value of this attribute is a 

objects (SROs) representative of the changed configuration. fist of objects, each one having it own structure. Each of 

Another earlier exemplary product that performs network these objects, such as the one labelled 2, is called a Port 

analysis is produced by Make System and performs network Object. A router consists of a set of physical ports, each 

analysis. The router objects in the earlier Make Systems tool, 45 having its own configuration. Each router's port in the 

however, are not executable. In other words, the Make invention is represented by a Port Object, which consists of 

Systems product can not automatically download configu- a list of structured objects itself Referring to FIG. 2, we see 

rations from a database to the live routers without requiring that there are ports 1 through N, representing N different 

a user to manually add configuration detail that the routers ports or the router. The number of ports on a router depends 

require in order to operate. Thus, output from the Make so on the type (i.e. make and model number) of the router and 

Systems product is not designed for automatic input of how it is physically configured. For an individual port, 

configuration information to live network routers. With the (labelled as (2) in FIG. 2), there are a number of attributes. 

Make Systems tool, problems are reported and it is up to the The first is media type, whose value can be Ethernet, Token 

network managers versed in the command set(s) of Bay Ring, Serial, Serial Link, FDDI, etc. We also identify a 

Networks Site Manager and/or Cisco System's IOS to select 55 number, which is used to distinguish between two ports of 

the appropriate router configuration commands to correct the the same media type. The next attribute is called 

indicated problems, reload these changes to each affected encapsulation, which indicates what type of encapsulation is 

router in the network and then run Make's "discovery" running on the connected media. An encapsulation example 

process to generate a data model for the analytical process is Frame Relay on a Serial media to distinguish it from a 

to be run again. As used herein, "discovery" means a live 60 HDLC serial. Further attributes include: bandwidth — which 

process performed on an actual network that identifies is a scalar metric used by the IGRP routing protocol that 

elements and their connections in the actual network, which relates to bandwidth of the connecting media. The attributes 

relies on the elements and their ports being operational also include delay — which is a scalar metric connoting the 

during the process. Contrast the difficulty and potential speed of the connected media and is also used by the IGRP 

inexactitude (room for human errors) of that process against 65 routing process. Hie next four attributes shown in FIG. 2 

the ability of the present embodiment of the invention to (labeled as (3)) are attributes related to access lists. Access 

assist the user in identifying potential problems via views lists are used to filter traffic coming in and out of the router. 
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Typically access lists are used for security purposes and 
routing purposes. Access lists are used to block or permit 
packets with either specific addresses or ranges of addresses, 
to be received or transmitted by a router. The first access list 
attribute illustrated in FIG. 2. (AccLstIP), stands for input 
access list, IP. This access list item is used to filter input IP 
packets. The attribute OutAccLat refers to filtering output IP 
traffic. Similarly, the attributes AccLstlPX and OutAc- 
cLatlPX refer to filtering input and output IPX packets. It 
should be appreciated that access information for other 
protocols, such as AppleTalk, has been omitted from FIG. 2 
for simplification. 

The last attribute under the port object is Port addr. Each 
port has one or more addresses assigned to it. The Port addr 
object has an attribute called "protocol" which refers to a 
particular address* level 3 protocol such as IP, IPX and 
AppleTalk. The address attribute gives the exact address. 
Port Addresses serve as building blocks for forming the 
topology information. 

The SRO structure accommodates multiple port address 
per port as any given port on a router may be running 
multiple protocols. For instance, consider a port configured 
for both IP and IPX. Typically such case, one would have 
both an IP and IPX address for this port. Another reason for 
having multiple port addresses is that routers produced by 
Cisco Systems, for example, employ a concept called pri- 
mary and secondary IP addresses where the user could 
address the same physical port with multiple IP addresses. 

Before discussing the next high level attribute of the SRO, 
Protocols, we consider the difference between this high level 
attribute and the subobject of the Port Object similarly 
named Protocol. The latter refers to the protocols) "run- 
ning" on the particular port. These port- related protocols 
define the type of the packets of data that come in and out 
of the router's ports (i.e., IP, IPX, AppleTalk, DECnet, etc.) 
By contrast, the high-level attribute Protocols refers to the 
routing protocols such as RIP, IGRP, OSPF, EIGRP and 
BGP, that the routers use to exchange information and build 
up the routing tables. 

The attribute Protocols comprises of a list of objects 
describing each routing protocol running on the router. The 
value of the "Type" attribute of a protocol object, labelled 4 
in FIG. 2, represents a type of routing protocol (e.g., RIP, 
OSPF, IGRP, etc.), and for some of the protocols, addition- 
ally a number. This number is used because a router could 
run multiple copies of some protocols, such as OSPF or 
IGRP, on the same router. The next attribute is Net 
Addresses. Typically a routing protocol is running on certain 
interfaces (i.e. ports) on the router. Each element in the list 
Net _Addr is an address capturing the ports (port addresses) 
the associated protocol is running over. This specification 
greatly simplifies the Protocol object; a current implemen- 
tation of the invention includes over 50 attributes associated 
with protocols. One skilled in the art will appreciate how to 
incorporate such router attributes into an SRO based upon 
this discussion. 

The next high level attribute of the SRO is Static-Routes. 
The value of the Static Routes attribute is a list of objects. 
Each one of these objects, labelled 5, refers to what is called 
a static route. There are basically two approaches to produce 
routes in a routing table. One approach is to run the routing 
protocols discussed earlier. The other approach is to directly 
code routes into the routing table. This latter approach 
involves specifying a set of static routes. A static route is 
identified by specifying a destination address Dest-Addr a 
next router address, which tells the router where to send a 
packet matching Dest-Addr which is discussed below. 
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The next high level attribute of the SRO is Access Lists, 
whose value is a list of objects, each object representing an 
access list. We earlier referred to access lists when we talked 
about port objects. For example, at the reference numberal 

5 6 we refer to an "input** IP access list. At reference numeral 
6, the SRO does not contain a whole access list, rather at this 
point in the structure there is a number referencing an access 
fist. Each access list object in the list Access Lists contains 
a full description of the access list and a number (see 

1Q reference numberal 7) used for reference elsewhere (such as 
at InAcclstIP). The Elements attribute in an access fist refers 
to a list of patterns which describe what addresses to permit 
and deny. 

Still referring to FIG. 2, we see an example of the next 

1S high level attribute called SRB Bridge Groups SRB stands 
for "Source Route Bridging," which is a mechanism for 
transporting traffic typically associated with Level 2 in the 
OSI model. There is also a variant of SRB bridging imple- 
mented in routed networks where SRB traffic can be encan- 

20 qulated over an IP backbone. SRB Bridge Group and RSRB- 
Peer objects are specified in the SRO. Each bridge group has 
a group number associated with it and a list of peers. Briefly, 
a pew is an object with an attribute specifying encapsulation 
type, which indicates what encapsulation method is being 

^ used to transport SRB frames. One example is TCP encap- 
sulated; another example, which Cisco Systems provides, is 
FST encapsulation. The other attribute of a Peer object may 
indicate the address of another router in the network where 
encapsulated SRB data should or potentially should be sent. 

30 Thus, to summarize FIG. 2, the information in the SRO 
captures a router's configuration. The information put into 
an SRO could be gleaned from a MIB or from a router 
configuration file, or from information regarding a planned 
or hypothetical network. A SRO structure, in accordance 

35 with the present embodiment of the invention, can serve as 
a neutral repository for configuration information from 
virtually any router vendor whether they use binaries or 
configuration files. 

FIG. 3 represents a Single Protocol Topology (SPT) 

40 object in attribute form, in accordance with a presently 
preferred embodiment of the invention. An SPT is formed 
for each of multiple Level 3 protocols (e.g. IP, IPX, 
AppleTalk). The SPT for a given protocol "P" represents a 
logical view of the topology from the perspective of that 

45 given protocol. The data structure in FIG. 3 indicates which 
router ports are configured to run protocol "F* and how each 
of these ports is logically interconnected with other ports 
that run protocol "P." A SPT for protocol P has a top level 
atomic attribute Protocol that is set to "P" (e.g., IP, IPX 

so AppleTalk etc.) and a top-level attribute CONNs (labelled 1 
in FIG. 3). which is a list of objects each called a Connec- 
tion. Each Connection identifies a list of router ports and 
their addresses all of which are configured to receive and 
transmit packets of protocol type P and are directly con- 

55 nected from a Level 3 perspective with respect to protocol 
P. As an example, for an IP SPT, all the ports fisted in the 
Connection will belong to the same subnet. We can say that 
all the ports in a Connection are directly Connected from a 
Level 3 perspective to clarify that at a lower level, at Level 

60 2, these ports might not be directly connected. For example, 
there may be bridges, LAN or WAN switches between these 
ports. If they are also directly connected from a Level 2 
perspective, then one could necessarily associate a single 
media type with the connection such as serial links, 

65 Ethernets, token rings, FDDI's, etc. 

FIG. 3 shows that each Connection object consists of a list 
of pointers. Each of these pointers refers to a port address in 
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a specific router. When representing a pointer in a SPT invention SPT topology formation involves processes that 

Connection we will use the form (Rt,Po,Pr) where Rt refers can take place "off-line." Specifically, in the current embodi- 

to a router's host name, Po refers to a router's port, and Pr ment of the invention, on-line configuration information 

refers to a protocol annotated by an index which is described typically is captured in one pass. After it has been captured, 

below. For example, (R1,S0JP1) refers to the first IP address 5 the formation of the SPT topology occurs off-line. In 

assigned to port SO (or in long form, Serial 0) on the router contrast, the Make System uses an on-line discovery process 

with host name Rl. This pointer links to a Port Address during topology formation. An advantage inherent in the 

object in a SROs (see the reference numeral 12 in FIG. 2) in approach to SPT formation in accordance with the invention 

a network under consideration. is that it not as susceptible to errors in determining the 

In giving the description of IP1, we said the "first" IP W proper configuration due to network devices and router ports 

address; the reason we said "the first IP address" is that it is bein g m a temporarily failed state. 

possible to assign two or more IP addresses to the same Another discriminating factor with respect to SPTs for- 

physical port. Cisco Systems, for example, refers to this mation is the fact that earlier tools typically focused mainly 

configuration feature as assigning secondary IP addresses on producing IP topologies because discovery is typically 

(as well the mandatory primary IP address) to a router port. 15 oriented towards IP. Some earlier tools also looked at EPX, 

Although the actual implementation of the invention makes but one of the disadvantages of discovery is that for a given 

a distinction between primary and secondary addresses, this protocol, one needs a certain level of instrumentation for that 

disclosure does not make this distinction, and simply states protocol to find the topology. Another disadvantage is that 

that a port has a set of IP addresses. Thus, in general a port one may need to use different discovery techniques to 

may have one or more addresses for any Protocol. Now 20 discover an IP logical view versus IPX or versus AppleTalk. 

suppose that two ports, SI and S2, respectively, on routers In contrast, an SPT formation process in accordance with the 

Rl and R2, are physically connected through a serial link ' present invention, handles all protocols using the same 

and both these ports have two IP addresses assigned. * algorithm. 

Furthermore, assume that the first IP address on SI, whose FIG. 4 is a generic procedure for forming a SPT for some 

pointer would be (R1,S1JP1) belongs to the same subnet as 2S protocol P from the set of SROs corresponding to the routers 

the first IP address on S2, whose pointer would be (R2,S2, spanning the network. When we say "generic" we mean that 

IP1) also suppose that the second IP address on SI, (R1,S1, this procedure, aside from a function called the SUBNET 

IP2), belongs to the same subnet as the second IP address on function, referenced in by numeral (3), is the same regard- 

S2, that is (R2,S2,IP2). In this case, although there is only \ css t0 whether P refers to IP, IPX, AppleTalk or DECnet, 

one physical medium connecting the two ports, that is a 30 etc. FIG. 4 provides a flowchart of the SPT build process of 

single serial link, the IP SPT containing routers Rl and R2 foe presently preferred embodiment of the invention. At Step 

will have two (logical) connections for this one serial link. (i) the Output SPTp is initialized (set to empty) to indicate 

Thus to summarize FIG. 3 a Single Protocal Topology that initially there are no connections in the SPT for protocol 

SPT is a data structure that can be produced for each Level P. 

3 protocol such as IP, IPX, and AppleTalk. A SPT for some 35 step 2 initializes a variable PA to the first port address of 

protocol P is a logical view of the topology from the protocol P in the list of routers. Given the set of SROs that 

perspective of protocol P. This data structure indicates which contain router information for the network under 

router ports are configured to run protocol P and how each consideration, the invention arbitrarily orders this set in an 

of these port are logically interconnected with respect to the ordered list. 

protocol. Although the network under analysis may contain 40 gtcp 3 ^ whcthef the (whicn ^1 be 

Uvel2devic*s,suchasbridges differcnl ^ protocol lQ vtoioco \) associated with port 

3 view, these devices are "invisible meaning, for example addresfi pA a]ready m ^ spT „ InitiaU ^ spT fe 

if there is a switch between two router ports in the Level 3 t tfae answer ^ ^ « no/ , £ fld ±& mov( £ to 

view, the ports are still viewed as being directly connected^ (5) M s (5) a new object ^ suboet 

A SPT differs from an SRO in that, wmle a single SRO altribute M {Q SUBNET (PA) is added to the SPT, A 

captures the configuration of a single router, a single SPT Connection object represents a particular connection 

captures the logical mterconnecUons of a set of routers. belween a M of fOUter ^ , f lfae answef was at Step 

The following discussion describes an earlier tool by (3^ ( m other words, SUBNETp(PA) is already in the SPT), 

Make Systems, and explains some significant differences in 5Q then the invention would skip directly to Step (4). Next, at 

the process that tool employs to create an SPT-like data ste p (4) a pointer is added under the subnet to that port 

structure and how that structure differs from the SPTs of the address PA. Next, after step (4), go to Step (7) and ask if the 

present embodiment of the invention. j as t port address has been reached. If so, the process is 

The Make Systems' internetworking product can use a finished because all the port addresses have been processed, 

"discovery" process, which requires a five network. Starting 55 If the answer is "no" then Step (6) is reached where PA is 

at a seed router (an arbitrary starting point on the live assigned the next port address and the process repeats itself 

network), the" tool reads the router's routing tables for the by looping to Step (3). 

next hop addresses to the neighbor routers. This process ifo definitions for the subnet functions are given in the 

continues in a breadth first manner to find the set of box on the bottom of FIG. 4. For IP, the input to the Subnet 

interconnected routers. This process also uses information, 60 function is 32 bit address Al and 32 bit mask Ml configured 

such as ARP (Address Resolution Protocol) information and Q n a port; the subnet function returns an address mask pair, 

configured interface speeds, in determining the valid router where the address-part is formed by applying the mask Ml 

connections. using bit-wise "AND" to address Al; the mask given as 

An important distinction is the fact that the Make Systems output is simply Ml. In the examples in this patent, we use 

process is a discovery process. It is inherently a live process 65 the address-part of the subnet as shorthand for the the entire 

which relies 00 live routers and their interfaces being subnet. For example 10.10.0.0 is used for [10.10.0.0 

operational. In contrast, the current embodiment of the 255.255.0.0]; in general this shorthand cannot be used, but 
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if the masks used as either 255.0.0.0 255.255.0.0 or 
255.255.255.0 and the zero subnet is not allowed, one can 
infer the mask from the address-part. 

The subnet functions for IPX and AppleTalk are trivial. 
For IPX, given the IPX network number as input, subnet 
returns this number as being the "subnet". Similarly, for 
AppleTalk, given lower and upper bound for a cable range, 
the subnet function simply returns this range as output. 

Thus in summary, the procedure iterates through all the 
port addresses in the set of routers and adds a pointer to each 
port address into the SPT structure grouping it with other 
port addresses belonging to the same. This basic SPT 
formation process is modified in practice to handle compli- 
cating factors that may arise in networks, such as, multi- 
point Wide Area Networks (WAN's), like Frame Relay, 
which is described later in this disclosure. 

FIG. 5 is a generalized block diagram of a simple example 
network that shall be referenced in a number of subsequent 
figures. In this network, there are two routers, Rl and R2. 
These two routers are directly connected through a serial 
link. In this and subsequent figures, ports are designated by 
an abbreviation for media Jype and a number such as "E0" 
on router Rl, which means Ethernet 0. On Rl*s E0 port, 
which is in the left of the diagram, we see that it connects 
to a symbol, labelled (1), which refers to an ethernet. Also 
associated with the ethernet are two numeric designators — 
"10.30.0XT, which is the IP subnet number of this ethernet 
in standard IP octet notation, and 9C, which is the IPX 
network number associated with the same ethernet. In other 
words, there is one ethernet designated at (1), but it has an 
IPX network number 9C and IP subnet number 10.30.0.0. 
Traversing the drawing from left to right, we see port SO 
(Serial 0) on Rl which is connected to a line that designates 
a serial link with HDLC encapsulation. Following to the 
other side of the link, we see the port SO on router R2. We 
can say that Router Rl, through a serial link is connected 
from port SO to Router 2 through Router 2's port SO. For 
serial links, like ethernets or other LANs, we can identify 
both an IP subnet, which in this case is 10.10.0.0 and an IPX 
network number, which is 7 A. Router R2 includes port E0 
(for Ethernet 0) which is labelled (2). This port E0 at (2) has 
IP subnet number 10.20.0.0 and IPX network numbered 98. 
In this example, we show a network where both EP and IPX 
are running on all interfaces. It should be appreciated that 
there may be networks in which different protocols run on 
different interfaces. For example, an interface might be 
running just one protocol or running none at all. Also, an 
interface could be running other protocols, such as Apple- 
Talk and DecNet. 

FIG. 6A shows the text configuration rile for Router Rl 
and FIG. 6B shows a text configuration file for Router R2. 
See, Cisco Systems, Inc. "Configuration File Load 
Commands", Router Products Command Summary, pp. 
6-584, Cisco Systems, Inc., 1992-1995. FIG. 7A illustrates 
the SRO that corresponds to Router Rl's text file, and FIG. 
7B shows the SRO that corresponds the text configuration 
file shown in FIG. 6B. 

Briefly stated, a text configuration file is put into SRO 
form using standard parsing techniques. In addition, certain 
default values also are entered into the SRO. There is default 
information that is implicit in the configuration rile. By 
omission, attributes still have values. As an example, refer to 
FIG. 6A and note where we designate (1), a bandwidth 
statement for Serial 0 Router Rl. Refer now to FIG. 7 A; at 
the point that is marked (1) is an associated bandwidth value 
of "1000". This bandwidth statement was explicitly coded in 
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FIG. 6A, and consequently was parsed and was explicitly 
put into the SRO of FIG. 7 A. In contrast, note in FIG. 6 A the 
version labelled (2), which is interface E0 for R2. In this 
case, there is no bandwidth statement. Referring to FIG. 7A 

5 at the point marked (2), Dote in the SRO the bandwidth is 
assigned the value 1000. The fact that the bandwidth at (2) 
and the one labelled (1) are both 1000 is just an artifact. By 
default, each of the different media, such as ethernet have 
bandwidth settings, which are the default values. These are 

10 values, for example, that a Vendor such as Cisco Systems 
makes public in documentation. Another example of default 
values is apparent in FIG. 6 A. No delay specification for 
either of the interfaces is coded in FIG. 6A, but referring to 
FIG. 7A at the regions labelled (3) and (4) delay parameters 

15 are specified. These were inferred knowing that Port [1] is an 
ethernet, which has a default delay of 100, and that Port [2] 
is a serial interface, which has a default delay equal to 2000. 

FIGS. 8A through 81 show a walkthrough of the flowchart 
in FIG. 4 (a depiction of the process for constructing the SPT 

20 for a given protocol). For this walkthrough, the inputs are the 
two SROs given in FIG. 7A and 7B. In this case, we will be 
producing a SPT for protocol IP. In the walkthrough, we will 
be referring to the steps which are numbe*red in FIG. 4 and 
discussing what happens at each step. The result will show 

25 the incremental build of the output, an IP SPT for the SROs 
of FIGS. 7A and 7B. 

In Step (1) the SPT is initialized. FIG. 8A shows the SPT 
at this point; protocol is set to IP and there are no connec- 
tions. 

30 In Step 2 the variable PA, which refers to a port address, 
is assigned the first port address (referring to FIG. 7 A, the 
port address marked (5) in the diagram). Note that the port 
address assigned has two ports 10.30.7.2 — which is the 
address — and 255.255.0.0, which is the mask. 

3S Step (3) asks the question whether the subnet associated 
with PA is in the SPT. The subnet for this PA is 10.30.0.0. 
The conventional approach to applying the subnet function 
for the IP protocol follows a simple rule: for each of the four 
octets in the address apply the corresponding mask octet 
using the bit-wise AND operation. For the special case when 
the mask octets are 0s and 255s, we can use the rule: if there 
is a 255, it means use the corresponding octet — if there is a 
0 that means ignore it (i.e. "zero out") the corresponding 
octet. Thus, given PA set to 10.30.7.2 255.255.0.0, we use 
the first to octets and ignore the last two, yielding 10.30.0.0. 
See, Comer, Douglas E., "Implementation of Subnets with 
Masks", Internetworking with TCP/IP, pp. 273-274, Pren- 
tice Hall Inc., 1991. 

50 Since the STP at this point is empty the subnet, 10.30.0.0 
is not in this SPT. Thus, the answer to the question in FIG. 
4, Step (3) is "no", and the process moves to Step (5) where 
the process adds a connection Conn[l] with subnet 10.30.0.0 
to the SPT. FIG. 8B shows the state of the SPT after this 

55 operation (Step 5). 

Step (4) adds a pointer to the current port address (referred 
to as R1,E0,IP1) under the connection that is labeled 
10.30.0.0. FIG. 8C shows the result after this step. 
Step 7 asks whether we reached the last port address. In 

60 this case, we have not — there is three more to process — so 
the proceeds to Step (6). 

In Step (6) the variable PA is set to the next IP port 
address, which is the port address labeled (6) in FIG. 7A. 
After Step (6), processing moves back to Step (3). 

65 At Step (3) the process computes the subnet for this new 
port address; — in this case, the subnet is 10.10.0.0 which is 
not in the SPT — so the answer to Step (3) is "no". 
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The process proceeds to Step (5) and adds a new 
connection, whose subnet is 10.10.0.0, to the SPT that it is 
building. FIG. 8D shows the state of the SPT after Step (5). 

Next, processing proceeds to Step (4) where a pointer is 
added to PA the pointer being Rl, SO, IP1 — under the subnet 
10.10.0.0, resulting in the structure in FIG. 8e 

Next at Step (7), since we are not at the last port address, 
the answer is "no"; thus processing moves to Step (6), and 
the port address is set to the next address which is shown in 
FIG. lb at the port address labeled (1). In other words, the 
port address is assigned 10.10.4.2 with mask 255.255.0.0. 

Processing moves back to Step (3), and computes the 
subnet for the port address, which is 10.10.0.0, and the 
answer to Step (3) in this case is "yes", because 10.10.0.0 
matches Conn[2]. 

Processing moves directly to Step (4), rather than going 
through Step (5), and simply adds a pointer to the port 
address under the matching connection (Conn[2]) (i.e., the 
connection associated with subnet 10.10.0.0.). Referring to 
FIG. 8F, there is shown the status at this juncture. 

The process proceeds to Step (7). PA is not the last 
address. So processing then goes to Step (jS) where PA is 
assigned the address which is shown in FIG. 7B at the port 
address labeled (2). 

Processing moves back to Step (3) and computes the 
subnet associated with PA which in this case is 10.20.0.0. 
The answer to Step (3) is "not in SPT", and thus processing 
moves to Step (5) and adds the subnet to the SPT resulting 
in the structure illustrated in FIG. 8g. 

Processing then moves to Step (4) where a pointer is 
added under Conn[3] (i.e., the connection associated with 
10.20,0.0) to this port address which is R2, EO, IP1 as shown 
in FIG. 8H. 

Processing moves to Step (7) and since processing has 
reached the last port address the answer is "yes" and the 
process is terminated. FIG. 81 shows the resulting SPT after 
all the processing is complete. 

FIG. 81 is the SPT for protocol IP. The data structure of 
FIG. 81 represents the IP connections shown in FIG. 5. It will 
be helpful to see how 81 corresponds to FIG. 5. Referring to 
the SPT in FIG. 81 at the region labeled (1), note that there 
is one subnet (10.30.0.0) that connects to just one pointer. A 
pointer is a link into the SRO substructure corresponding to 
a port address. The single pointer under Conn[l] (in FIG. 81) 
links to Router Rl's port EO's only IP address. Conn[l] can 
be interpreted as capturing that subnet 1030.0.0 which has 
one router point attached to it, namely router Rls E0. Since 
'E' refers to an ethemet, this connection can be associated 
with an ethemet. Next, refer to Conn[2] in FIG. 81, and note 
that this is associated with subnet 10.10.0,0, which is 
labelled (3) in FIG. 5, the Serial Link. This serial link 
connects two ports, represented in the data structure by the 
two pointers associated with Conn[2]. Lastly, Conn[3] cor- 
responds to subnet 10.20.0.0, which is an ethemet with a 
single router port attached, Router R2's E0. 

FIG. 8J shows the SPT that would be produced if the 
procedure in FIG. 4 were applied to SROs in FIGS, la and 
lb for protocol IPX. A difference between the IPX and IP 
waflcthough are that, for IPX, PA will be assigned IPX port 
addresses. Another difference is that for IPX a SUBNET /F;r , 
rather than SUBNET^ would be used in Step 3 of FIG. 4. 

It will be apparent from the foregoing discussion that 
there exist only minor distinctions in the process of building 
the SPT among certain different protocols. If the process of 
FIG. 4 was building an AppleTalk SPT, it would step 
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through AppleTalk port addresses. Another difference is the 
function "subnet" which is specified in FIG. 4 at Step (3). 
For the different protocols there are different subnet func- 
tions. We described earlier that for IP the port addresses 

5 which are given by an address and mask — the invention 
applies the mask using "bit- wise AND," and then does the 
comparison to get the subnet from the mask/address com- 
bination. For IPX, the condition is much easier. The inven- 
tion simply uses the address specified in the port address 
which is the IPX Network Address. Once again, referring to 

1 FIG. 7A, the region labelled (7), note the address is 9C. Next 
reference FIG. 8J and observe that the subnet is simply the 
network number 9C. 
Thus, a significant advantage of the processes and struc- 

1S tures of the present invention over earlier network manage- 
ment tools is with the present invention, one needs go to the 
live network only once for each router to populate the SROs. 
When the SROs are populated, the formation of topology is 
strictly an off-line process that can proceed even if the 

2(J network at that time has regions that are not operational. 
This is in contrast to other mechanisms which uses (on-line) 
discovery for topology production. 

Another advantage of the invention is in creating topolo- 
gies for two networks that are separate, but are to be merged. 

25 Using the methodology of the present invention, one can 
obtain the router configurations for one of the networks; go 
to the second network and get the router configurations even 
though they are not connected at this moment; merge them; 
load the configurations into SRO's; make modifications to 

3 q the configurations to be sure the networks intemperate 
properly; and perform analysis of the newly merged net- 
works. Generally, earlier network management tools cannot 
be used to form a topology unless the two networks are 
merged. 

35 FIG. 9 shows an extension of the SET Build process 
shown in FIG. 4. The process in FIG. 9 handles a compli- 
cation where it is possible, due to misconfiguration that ports 
on two different routers are given the same address. This is 
high seventy integrity check, a problem that the network 

40 manager wants to correct on the network without delay. The 
problem is somewhat analogous to a situation where, you are 
mailing a letter, and two people have the exact same address. 
It is not clear who you would sent it to. During the process 
of forming the topology, a search is made for duplicate 

45 addressees. FIG. 9a shows the steps from FIG. 4 and inserts 
the additional steps that look for duplicate addresses. 

Focusing now only on the the additional steps add in FIG. 
9, Step la, is inserted between Step (1) and Step (2). Step la 
sets the duplicate address set to empty. The process in FIG. 

50 9 will produce not only the SPT, but also an integrity check 
output set that conveys which port addresses refer to the 
same address. The comments on the bottom of FIG. 9 
provide an example of what this set might connote. For 
example, consider the DuplAddrSet (which is a set of sets) 

55 with elements {PA1, PA3, PA4} means that the port address 
pointed to by PA1, PA3, and PA4 all refer to the exact same 
address. Similarly, the presence of the second set, {PA9, 
PA7} means that PA9 and PA7 refer to the same address. A 
conflicts are identified, the set DuplAddrSet will grow. 

60 In Step (3A), if the process finds that the subset of the port 
address being processed is already in the SPT, then it is 
necessary to determine if in that SPT there are any duplicate 
addresses. (If the subnet is not in the SPT, it is not necessary 
to do the check since an address equal to PA cannot be in the 

65 SPT.) If there aren't any duplicate addresses detected in Step 
3(A), the answer will be "NO** and we process as normal, 
going to Step (4) as it appeared in FIG. 4. 
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Now, back to FIG. 9, Step 3A; if the test in this step The overlap function for AppleTalk (shown in the second 

detects an address conflict, then processing goes to Step 3. box in FIG. 10) takes as arguments two (Appletalk 

Step 3b is a test that checks to see if already, in "subnets", each which is given by a lower and upper bound 

DuplAddrSet, there exists a member (i.e., a set of port giving a cable range. The definition for OverlapAppIeTalk 

address pointers) having same address as PA, the current 5 [[cbrlbl cbrubl], [cbrlb2 cbmb2) can be interpreted as 

port address). If the answer is Yes, then the matching sa y in 8 mat the cable ranges [cbrlbl cbrubl ] and [cbrlb2 

element is extended to include a pointer to PA If it doesn't, cbru b 2 ) overlap if and only if it is the case that they are not 

we add a new member to DuplAddrSet containing a pointer equal and not disjoint. 

to PA and a pointer to the port address in SPT exactly Remember that we are sequentially moving through over- 
matching PA Thus, Steps labeled (la), (3a), (3c), (3b) and to aU the processes described in FIG. 1. We have already talked 
(3a), are added in FIG. 9 to look for duplicate addresses and about the P rocess of takin g texl configuration files or MIB 
put them in this duplicate address set, DuplAddrSet. data and producing SROs (FIG. la). Given the SROs for 
^ r ^ . t_ . .x. • c t each of the protocols that runnmg on the network, individual 
Referrmg to FIG. 1 note hat the mvenUon forms topol- sPlfc are formed (part of what is done in FIG. 16). Given 
ogy mforma ion and then determines whether there are any eacb of ^ ia6ivi ^ SFIs, there are a number of integrity 
mtegnty violations (FIG. Id and lg). TT,e addr«* set is the » ^ of what ^ don6 ^ mQ For each 
resultofoneoflhemtegntychecksreferredinHG.W^ ^ ^ ^nti&ed in the associated 

18 mfonnaUO K I ! ^ USer Can ,t Pply m RG - ** protocol Additionally, for IP, overlapping subnet masks are 

to find if there are problems and remove them. identified «» 

FIG. 10 shows a procedure for calculating another integ- Next> we provide examplcs of thc production of views in 

rity check, which is applicable to IP using an SPT. In IP, not accordance ^th the process represented in FIG. lc. The first 

only do you want to make sure that two addresses do not cxample fc mustrated m mG u ^ term « vicw » M ^ 

exactly match, but also you want to be sure that address/ herein means ao abstfact representatioB of a leve i 3 topology 

mask pairs, which intuitively refer to address ranges either that omits irrelevant elements and logically groups elements, 

refer to the exact same ranges or do not overlap at all. We FIG n provides a ^ which &oups routers together to 

don't want the case where they overlap. &hQW which roulers ^ LANs share me same campuses . In 

FIG. 10 illustrates a general procedure for computing the FIG. 11, we show campuses labeled C2, CI and C3, each 

"Overlapping Address Range" integrity constraint, which is containing routers and LANs. Referring to C2 first, we see 

applicable for protocols, such as IP and IPX that allow mat ro uters R3, R4 and R2 are grouped together appearing 

interfaces to be configured with address ranges. (Note: an IP 30 m Campus C2. Referring to C3 next, we see that router R5 

subnet as we will see, can be thought of as corresponding to and R6 mc grouped together and if we look at CI, we see 

an address range. that there is one router in this campus, Rl. To understand 

The input to the "Overlapping Address Range" flowchart how this information is captured in data structures, in 

is the SFT for the protocol being analyzed, which for our accordance with the invention, refer to FIG. 12, which 

invention can be IP or AppleTalk and its output, the set 35 provides an example of a "View" data structure in instanti- 

Conflicts, whose elements are the pairs of connections in the ated form. The same basic type of data structure framework 

SPT being analyzed that refer to overlaping address range. is used for the different type of views. The first element in 

In step (1) of the flowchart (FIG. 10), the output variable this View data structure is the atomic attribute "Type*' set to 

Conflicts is initialized to the empty set In Step (2), the "Campus" to distinguish it from different views, such as the 

variable Conn is set to the second connection in the SPT. 49 OSPF view. The next attribute, "Group"; is a list of objects, 

(Note: if there is only one connection in the SPT then there each of them being what we call a "Group", which shows 

cannot be any conflicts and we assume this procedure would how the routers, links and LANs, or in our terminology 

not be applied). In Step (3) the process looks for any "Connections" tie together. Going back to FIG. 12, refer to 

connections in SPT listed before Conn that overlaps with it; reference-numeral (1), which refers to an object with name 

if any overlap is found, a set containing the two overlapping 45 CI. The next attribute Conn refers to a list of pointers to 

connections are put in as a member of Conflicts; in the connections in the SPT being abstracted. These connections 

bottom of FIG. 10 we show the definitions of the Overlap are the links and LANs that belong to the group. In FIG. 12, 

functions, which are the only part of the algorithm that in the group with name CI, we see that the Conn[3], which 

differs from protocol to protocol. In Step (4) the algorithm corresponds to the ethernet 10.20.0.0, is a member. In FIG. 

checks if the last connection has been reached; if so, 50 11, this ethernet is within the CI campus group. Groupings 

processing terminates; if not processing goes to step (5) have two parts, the connections and the routers. In CI of 

where Coon is set to the next connection and processing FIG. 11, note that router Rl is in this grouping. Refer to the 

repeats for this new connection starting at Step (3). Router List attribute at region (6) FIG. 12 where there is a 

The overlap function for IP (shown in the first box in FIG. pointer to just a single router, RL 

10) takes as arguments two IP subnets, each which is given 55 Io FIG. 12 reference numeral (2) indicates a pointer into 

by a 32 bit address and 32 bit mask. The subnet given by [Al SPT. Many of the data structures of the present embodiment 

Ml] defines the range of addresses from Al to "(A1|~M1)", of the invention are intertwined data structures that connect 

where "|" refers to bitwise OR and to bitwise negation. the topological information to the SRO information. 

The expression "(A1|~M1) can be thought of producing a 32 Referring to reference numeral (3) in FIG. 12, a group 

bit number formed by flipping the bits in Al that were 60 corresponding to campus C2 is shown. The connection that 

masked out (which are the ones where Ml has Is) from 0s belongs to it is Conn[l] and the routers that belong to it are 

to Is. The definition for OverlapIP([al ml],[a2 m2]) can be R2, R3 and R4 (shown at Point (4)). The last group 

interpreted as saying that subnets [al ml] and [a2 m2] (reference number 5), corresponds to campus C3; it has three 

overlap if and only if it is the case that they are not equal and connections associated with it, Conn[5], [6], and [7] and two 

not disjoint, now two addresses are disjoint if the lower 65 routers, R5 and R6. Note that a view might not contain all 

bound of one of the ranges is greater than the upper bound routers or all connections that are contained in an SPT. It 

of the other. merely describes the elements that are relevant to the 
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abstraction. In a campus view, some of the connections may 
be omitted. Connections belong to a campus view only if 
they are LANs. So, for example, Conn[l] in FIG. 11 is a 
FDDI and is in C2. We see that Connp] is an Ethernet, and 
that is in CI; also connections Conn[7], Conn[6] and Conn 
[5], which are all Ethernets, are in C3. There are two 
connections, serial links (Conn[2] and Conn[4]) in FIG. 11 
that do not appear in FIG. 12, because serial links do not 
belong to a particular campus; rather they span campuses. 

FIG. 13 is a flowchart that illustrates a process for 
constructing a campus View object given as input, an SPT 
and the SROs that are pointed to by the SPT. In FIG. 13, we 
refer to S¥Y p , where **P' can stand for any protocol since 
basically the same is used for multiple protocols, e.g., IP, 
IPX, AppleTalk etc. 

Referring to FIG. 13, we first initialize the view object 
(VW) to "empty" and set Type to "campus". Next, at step 
(2), the variable Conn is set to the first connection in SPT 
(really SPTp). In the following discussion, realize that the 
view object formation process iterates through all the con- 
nections in the SPT under consideration. 

In Step (3), we ask whether the Conn variable is associ- 
ated with a LAN. If the answer is "no", (in other words, 
Conn is associated with a serial link or any other wide area 
link) then the connection is ignored and processing goes to 
Step (4), which asks whether the last connection in SPT been 
reached. If it has, the procedure terminates. If it has not, then 
Conn is set to the next connection in the SPT, and processing 
goes back to Step (3). 

On the other hand, at Step 3, if the Conn is a LAN 
connection, we go to Step (6), which asks whether there is 
a group in a view already having one or more routers in 
common with those pointed by Conn. (Remember that Conn 
is a connection in a SPT, which has pointers to port 
addressees, and each port address belongs to a router). If the 
answer is "yes", then we go to Step (7) and add to this 
existing group in the view a pointer to Conn under the Conn 
attribute and pointers to all routers associated with Conn 
under the Router list attribute. If the answer to Step 6 is "no", 
then processing goes to Step (8) where we create a new 
group. We give each group a unique name, (Campus CI, 
Campus C2, etc.) We add a pointer to Conn connection and 
to all routers pointed to by this connection. After this step, 
we go back to Step (4) and find out if we reached the last 
connection. If not, iterate to the next connection. Similarly, 
after Step (7), we gp back to Step (4) ask whether we have 
reached the last connection. If not, we continue to process 
connections until we have processed them all. So, the result, 
upon answering "yes" in Step 4 is that the process terminates 
and the object VW (the view object) will be fully instanti- 
ated. For example, for the network view in FIG. 11, we have 
a view object like that in FIG. 12. 

We will next provide an example involving the formation 
of an OSPF view. OSPF is a particular routing protocol. See, 
Spohn, Darren L., "Router Protocols", Data Network 
Design, pp. 192-213, McGraw-Hill Inc., 1993. Also, see the 
following Requests for Comment issued by the Internet 
Engineering Task Force (IETF): RFC 1771— A Border 
Gateway Protocol 4 (BGP-4) specification; RFC 1131— 
OSPF specification; and RFC 1058 — Routing Information 
Protocol (RIP). Basically, routers run routing protocols in 
which they exchange and generate information to produce 
routing tables. For OSPF, a network is grouped into areas 
with some routers called area border router, responsible for 
exchanging information between areas. 

FIGS. 14 through 17 deal with creating an exemplary 
OSPF View. FIG. 14 gives an intuitive picture of an exem- 
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plary OSPF view. FIG. 15 shows an example of a data 
structure that captures the OSPF view of FIG. 14. FIGS. 16a 
and 16b are portions of the SROs for the routers shown in 
FIG. 14 that are relevant for the analysis. Finally, FIG. 17 is 

5 an IP SPT that was formed for the routers in FIG. 14. 

Referring to 14, there are two Areas, Area 0, 
(encompassing routers Rl, R2 and R3) and Area 1, 
(encompassing routers R6 and R5 and a group with a single 
router 4) which is the area border router between Area 0 and 

10 Area 1; to be more specific, R4 is running both Area 0 and 
Area 1. 

Referring to FIG. 15, there is shown a View data structure 
that captures the grouping of FIG. 14. The View object Type 
is OSPF. The View object's TYPE attribute distinguishes it 

1S from other View objects, such as the campus view TYPE. 
Next, note the groups attributes. The group attribute com- 
prises a list of group objects. The first group refers to Area 
0, the connections in that group are, Conn[l], [2], and [3], 
and the routers in the group are, Rl, R2 and R3. The next 

20 S rou P refers to Area-1, which includes Conn's [4] thru [7] 
and routers R5 and R6. Finally, there is a group for the area 
border router R4. 

FIGS. 16a and 16b illustrate how router configurations as 
captured by the SROs contain the information that is used to 

25 indicate which areas the different routers correspond to. In 
FIG. 16a, we see that the SRO for router Rl is running an 
OSPF process, OSPF 1. Note that a router can be running 
many different OSPF processes. For simplicity here, we only 
consider cases where a router runs just one process. At 

30 reference numeral (1), we see that the OSPF process on 
router Rl has an attribute called Net Address, which refers 
to a list of statements indicating what areas the different 
router interfaces belong to. To find out if an interface 
belongs to a particular area, you sequentially go down the 

35 list of network statements looking for a match. Referring to 
FIG. 16a, the process for finding a router interface's area 
involves first starting network statement object labeled (la) 
and seeking a match. If there is no match, then the process 
proceeds to the network statement object labeled (lb). If no 

40 match is found in any of the Net-addrs, this interface does 
not belong to any Area and is not considered in an OSPF 
view. 

The actual matching process is as follows. Consider the 
item la that has 9930.0.0 and 0.0.255.255 as it matching 

45 pattern. Referring to FIG. 14, we see router Rl, port SO has 
an address of 99.30.20.1, which matches 99.30.0.0 and 
0.0.255.255. The second part, 0.0255.255, is called an 
access list mask, to distinguish it from the masks found on 
IP port addresses. For "port address'* mask, the Octet, "255" 

50 mean "consider" the corresponding address octet during the 
matching process, and "0" means ignore the corresponding 
address octet. For access lists, the meaning of the matching 
octets are reversed. "255" means ignore the matching 
address octet, and"0" means consider it. So for example, the 

55 pattern at the network statement (la) means look for 
addresses that start with 99.30 because there is a correspond- 
ing 0.0 matching octet, but ignore the rest of the address 
because the mask ends with 255.255. So we see that Rl, SO 
has address 99.30.20.1 which matches item la in FIG. 16a, 

60 and consequently Rl, SO belongs to Area 0. Referring to 
FIG. 14, Rl, E0 has address is 10.2035.1. This does not 
match item la but does match item lb so this interface (E0 
on Rl) is in the specified area Area 0. In summary, looking 
at FIG. 16, we see that both interfaces, SO and E0 for router 

65 Rl, shown in FIG. 14 match Area 0. 

As another example of interface matching in OSPF areas, 
refer to reference numeral (2) in FIG. 16. Now refer FIG. 14 
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at Router R4. Router R4 has two interfaces, Fl whose this connection with ports that run OSPF, and we go to Step 

address is 20.20.10.1 and SO whose address is 98.40.10.1. (7) meaning that we gp on to the next connection, if it exists. 

Now going back to FIG. 16A, reference numeral (2) shows At Step (7), the process checks whether the last connection 

the network statements for router R4. The first network has been reached. If it has, processing terminates. Otherwise 

statement reference numeral (2) shows the pattern 98.40 5 processing goes to Step (7a) where Conn is set to the next 

(ignore the rest of the bits). This matches Serial 0's address connection and the process iterates through the loop again 

(98.40.10.1), and thus this interface is in area 1. However, g° in S back lhrou g h ( 4 ) t0 ( 5 )> ctc - 0a the othcr hand > lf ^ 

Fl's address (20.20.10) does not match the first network conflict m which there are two or more areas associated 

statement, (the statement at reference numeral 2 in FIG. ™ th a single connection, then Conn processing from Step 

\ i_ -i^i** * t_ -»t tu ri (5) goes to Step (6) where the connection Conn is put m 

16a), but the second network statement matches 2b. Thus Fl 10 a- * 

n » . . , u » » *. i . * OSPF__conflicts. 

(from router R4) is in the area specified by network state- . A , , . . 

. it ■ a n Another case arises when the connection is only associ- 

ment 2b. i.e., Area 0. . , . . . , . , M . 

9 * ated with one area in which case the process continues to 

For the routers running OSPF, determining what areas Step (gy Io step (8), just for convenience "Area_Ar" refers 

their interfaces match is an important step in the algorithm to me case w here there is a single element in AreaSet. 

for producing the OSPF view. Very briefly, if there is a router « ^ Stcp ^ processing proceeds to Stcp (9) which ^ 

that has one or more interfaces, all of them belonging to the whethef ^ afea ^^ied with connection Conn is already 

same area, then this router will be put in the group for this m me ^ If it ^ m the View, then we want to add this 

area. For example you see that routers Rl, R2 and R3, in COQnection under this area which fe accomp lished at Step 

FIG. 14 have all their interfaces match a statement associ- (10) Qn ^ mher haQd tf ^ afea associaled ^ Conn ^ 

ated with area 0 On the other hand, router R4 has interfaces 20 ^ ^ ^ ^ ^ lQ § (U) wfaere a Qew 

that match two different areas, so it is in its own border area labeled fe CTeated and under which tnere 

group. Sinularl^routersRS and R6, have all their mterfaces fa added a ^ tQ Conn From botfa s (n) ^ d ^ 

match area 1. Thus, R5 and R6 are in area 1. processing goes to Step (12). 

An advantage of multiple views is if you have a particular Steps ^ through (17) are responsible for putting routers 

task at hand, then a specific view might be particularly po inted to by Conn under the appropriate area if they have 

suitable. The OSPF view, for example, is a view that would Qot alrcady bccn placed Recall that a connect ion points to 

be useful for configuring OSPF. In configuring OSPF, a a xt of port addrcsscs each one of them corresponds to a 

central concept is specifying what areas each router, running router We set variable PNTR to the first pointer in Conn at 

OSPF belongs to. So being able in a very succinct way, to s(ep qj). We then go on to (13), which asks whether a router 

observe the area groupings is an enormous benefit in gaining associated with this pointer is in the View already". If the 

a more comprehensive understanding of how the OSPF answer is yes, then we do not have to process this router and 

processes are running. we go on to Step ( 16 ) ? which ^ whe ther PNTR is the last 

Placing a router in the wrong area is a very easy mistake pointer in Conn. In other words, it asks whether we have 

to make. For example, in typing in a configuration, a user's 35 finished processing the routers in Conn. If that is the case, 

mistyping 1 instead of 0 in a single area statement changes then we go on to Step (7) to process the next connection. If 

what areas a router's interface is in. Thus, it is very helpful not, we go on to (18) to process the next pointer (more 

to have a view based upon OPSF areas to permit easier particularly to the router pointed to by this next port address 

diagnosis of errors, for example. pointer and go back to Step (13)). 

As we mentioned, FIG. 17 is the IP SPT, which will be 40 In Step (13), if the router associated with PNTR has not 

produced by running the algorithm we described in FIG. 4 been processed already, we go to Step (14) and ask how 

on the SROs corresponding to routers Rl to R6. many areas the router pointed to by PNTR has. FIG. 20 

FIG. 18 is a flow chart which shows how the OSPF View shows detail of how the answer to this is computed. If the 

is produced with the inputs being the IP SPT its related answer is zero, in other words this is a router which is not 

SROs. In the course of producing the OPSF View, an 45 running OSPF, then we just go on to Step (16). If the area 

integrity check is performed which determines whether there answer is 1, then we know that this router is running one 

are two adjacent routers running OSPF that have their area > Area_Ar and thus we put it under group Area_Ar 

connected ports assigned to different areas. This condition is under me Router Lists attribute. On the other hand, if the 

a misconfiguration that should be pointed out to a user so he router is running in more than one area, then we know that 

or she can correct the error. In step (1) of FIG. 18, the main 50 * k a border area router, and we construct a special group 

object we're building, the VW object is set to empty with for mat router - T^ 1 happens in Step (17) where we create a 

Type set to OSPF. In Step (2), the OSPF Conflict set is ° ew group called "Border Area" and a pointer to the single 

initialized to empty. In this algorithm, we will be iterating router ^ this g rou P- In me View of F 10 - 14 > R4 is one 

through the connections in the IP SPT. So in Step (3) of these border routers, and hence belongs to its own group, 

variable Conn is set to the first connection in the IP SPT. 55 FIG. 19 is a flow chart which explains details of Step (4) 

Next, in Step (4), the AreaSet is assigned the set of areas in FIG. 18. This is a procedure, which given as input a 

associated with Conn's pointers. We will go into detail about particular Connection in a IP SPT, indicates all the areas 

this process in FIG. 19. If connection Conn has one or more associated with the router ports which are attached to this 

ports which are running OSPF, then Conn will be processed. connection. Let's start at Step (1) in FIG. 19. As an overview 

On the other hand, if no ports are running OSPF, it is 60 of the following discussion of FIG. 19, the process for 

ignored. If it is the case that there is a conflict as, for associating areas and router ports involves iterating through 

example, when one port attached to Conn has area 1 the pointers contained in the input connection, or in other 

associated with it, and another port attached to the same words, iterating over all the routers that are connected to the 

Conn has area 0 associated with it then AreaSet will have input connection Conn. At Step (1), PNTR is set to the first 

more than one element. So let us see how this is done. In 65 pointer in Conn. 

Step (5) we ask "how many members are in AreaSet." If the Step (2) asks if a given router pointed to by PNTR has the 

answer is "0" that means that there are no routers touching routing process OSPF configured. If the answer is "no" then 
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the procedure does not have to process this given router At iterate through the loop to determine whether there is a 

Step (3) a determination is made as to whether PNTR is the match. Now referring again to Step (6), if a match is found, 

last pointer in Conn. If it is, then processing is finished. If then the area mentioned in the Netstmt is added to the 

not, the process moves to Step (4) in which PNTR is set to AreaSet, and the procedure goes to (10) to process a new 

the next pointer in CONN. The process then returns to Step 5 P ort address. 

(2). On the other hand, if the given router has OSPF The following discussion addresses some of the issues 

configured, Step (5) is reached. mat U P ^th a multi-point WAN, such as Frame Relay. 

„ 4 lL 4 - . ... . i . We will first give an intuitive description and then show how 

Note that for simphctty we assume that a rou er only has we ^ ^ ^ m ^ 4 tQ for ^ 

one OSPF process, if it has any. The actual implementation Ucat f 0QS mat me multipomt WAN introduces. Let us 

of the preferred embodiment, however, can handle multiple io ^ ^ wi(h aQ mmitive view of an exemplary network 

OSPF protocols on a single router, and this process depicted [ n FIG. 34, which shows 4 routers Rl, R2, R3, R4 

described herein naturally extends to cover that situation. that m connected through a Frame Relay cloud. Each of 

At Step (5), for convenience, we let OSPF„obj refer to these routers attach to the Frame Relay cloud through its SO 

the OSPF object associated with the router pointed to by port. As far as the Level 3 view is concerned, all the routers 

PNTR. The process then proceeds on to Step (6), which asks 15 that hook into the frame relay, such as, Rl and R2 are one 

whether the OSPF___obj has any network statements. If the hop away. Another consideration to note is that all the SO 

answer is "no", then the process go back to step (3) and port addresses for all the four routers belong to the same 

iterates through and processes the next router. If the answer subnet, 117.33.4.0. If we took the algorithm, described in 

is "yes" then "Netstmt", becomes the first "network state- FIG. 4, (or even with the extensions shown in FIG. 9) and 

meat" in OSPF obi. 20 J ust sull P\y applied it to the description of this network as 

r /w\"Ti_ " i- si*\ *l *l u given by its SROs, we would produce the SPT depicted in 

In steps (7) through (11), One process goes through | IG . SFrm nG. 35 shows that Rrs,R2's,R3's and 

sequentially the list of network of statemente assorted with R4?s ^ ^ m aUached tQ subnet . u 7.33.4.0. The 

the OSPF process to see if the address associated with PNTR assumptioa of thesc four ports ^ the same grouping 

matches one of those statements. If so, then the process uses ^ fa that ^ all could directly reach each other, or in network 

the area number associated with that network statement. At ^rms, that they are "fully meshed". For a LAN this is the 

Step (7), the process makes Netstmt the first network state- case; all me connected ports can directly communicate, 

ment. Step (8) asks an address associated with PNTR A potentia i pro blem, however, is that in a multipoint 

matches the network statement". The details of this match- WAN> such ^ p rame Re j ay f or cxamp ie, the connected 

ing process are described earlier in this specification. If there ^ routers may not be fully meshed. For example in FIG. 34 we 

is a match, then the process proceeds to Step 11 which adds snow tnat mere ^ on i y a partial meshing. The dotted lines, 

the area mentioned in the network statement to the output m ifa Frame Relay cloud in FIG. 34, are there to convey that 

AreaSet if it is not there already. Processing then goes back me pa i re 0 f routers that can directly "talk" are: Rl and R2; 

to Step (3) to process another router, if any are left. On the rj R3; Rl and R4; and R2 and R3. This is not a full 

other hand, if at Step (8), the address does not match the ^ mes hing, for example, because R4 cannot directly talk to R3. 

network statement, then the next OSPF network statement is ^ important ^pect of capturing a Level 3 view is 

processed, looking for a match, if it exists. capturing the fact that R4 and R3 are not directly connected. 

FIG. 20 depicts a flow chart that describes in detail Step if we ^ the SPT in FIG. 35, we are not capturing that 

(14) in FIG. 18, it asks how many areas a particular "router" distinction. Instead, we can use the SPT in FIG. 36 to 

is associated with. We contrast this with the process in FIG. ^ represent this incomplete meshing. FIG. 36 shows four 

19 which is the question: how many areas a "connection" Connections, all with the same subnet 11733.4.0. These four 

has associated with it. Connections show the directly connected routers in the 

The first step in FIG. 20, labeled. (0), is to set the output Frame Relay Cloud. 

AreaSet to empty. The process next goes to Step (1), and There are a number of sources of information about 

asks "whether a router has OSPF configured". If the answer 45 meshing in a multipoint WAN, such as Frame Relay. One 

is "no", then the process is finished, and the output area set mechanism to determine the meshing is by the inclusion in 

is empty. If the answer is "yes", the process proceeds to Step the router configuration text of explicit Frame map com- 

(2). For convenience the variable OSPF_obj is set to refer mands. Looking at FIG. 38a at reference numeral (1) there 

to the OSPF object associated with the input router. The appears command, "Frame Relay Map IF*, and the address 

process then goes to Step (3) which asks whether this OSPF 50 11733.4.2 and the number 100 (and the term "broadcast" 

object has any network statements. If it does not, then the which is not relevant to the disclosure). This command 

process exits with the answer being that the area set is empty. which is associated with router Rl's SO port is saying that 

If it does, the process goes to Step (4) and iterates over the SO is meshed with the address 117.33.4.2, an address of R2. 

port address on this router. Step (4) lets the variable PA be So, reference numeral (1) in FIG. 38a corresponds to the 

the first IP port address of the input router. The process then 55 dotted line marked (1) in FIG. 34. Similarly, referring to the 

goes to Step (5). second line under the Frame Relay Command, in FIG. 38a, 

Step 5 lets Netstmt be the first network statement in the we see mention of address 117.33.4.3 which corresponds to 

OSPF object. Next, Step (6), asks whether PA (the Port the dotted line that connects Rl to R3 in FIG. 34. Referring 

address that is currently being processed) matches the net- next to FIG. 38*, at reference numeral (3), we see the 

work statement, Netstmt. This notion of matching is the go mapping from Rl to R2 in the other direction: from R2 to 

same as that described at Step (8) of FIG. 19. If there is no Rl. In summary, the presence of the map commands in 

match, go to Step (7) and the last network statement has been router configuration files is one source of information to 

reached. If the last network statement has been reached, go determine the meshing in a Frame Relay cloud, for example, 

to Step (10) to process the next port address on the router. This information often can be obtained from text files, such 

In Step (7), on the other hand, if the last network state- 65 as those shown in exemplary FIGS. 38a through 384. 

ment has not yet been reached, then go to Step (8), and we In FIG. 37 there is shown a fragment of the SRO for router 

set the variable Netstmt to this next network statement and Rl that focuses on how the Frame Relay maps in FIG. 38a 
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translate into the SRO. Referring to reference numeral (1), 
note that there is an attribute for port SO, which is a list of 
Frame Relay map objects. In FIG. 37, each one of these 
items under Frame Maps labeled (1) which items are labeled 
(2), (3) and (4), correspond to the three Frame Relay Map 
commands that are present under interface SO in FIG. 38a. 
It is a straight -forward translation. Another process for 
determining the meshing in a multi-point WAN is referring 
to the live router and executing a "Show Frame Map*' 
command, parsing the response and bringing it in the SRO. 

To handle the complications due to a multi-point WAN we 
have to modify the SPT algorithm that we described in FIG. 
4. To show how we modify this algorithm, we repeat 
diagram 4, labeling the boxes with letters, rather than 
numbers, which is given in FIG. 31. We show the additional 
processing steps, labeled with numbers, that modify it (FIG. 
32) and then we'll just apply the modifications and the show 
the resulting flowchart (FIG. 33). In FIG. 33, the previous 
steps are labeled with letters, while the new ones are labeled 
with numbers. 

Referring to the Step labeled (C) in FIG. 32, which is the 
same as Step (C) in FIG. 31. Step "C" is a test to see if the 
subnet for the port address being processed (PA) is in the 
SPT. If the case is "no" then we go to (D), which is normal 
processing, and reiterate the process with the next port 
address. On the other hand, if the Subnet (PA) is in the SPT, 
processing gpes to Step (1), which asks whether the port 
associated with the PA is Frame Relay encapsulated. This is 
determined by looking in the encapsulation attribute of the 
port associated with PA in the SRO. If this is not the case, 
then normal processing takes place and the procedure goes 
to (E) (again as depicted in FIG. 31). If not, go to the special 
Frame Relay multi-WAN processing, in other words we go 
to Step (2). In Step (2) the variable FRM is set to the set of 
Frame Relay maps associated with PA's port. The process 
iterates through this set by first setting FRM_member to the 
first element of FRM (Step (3)). In Step (4) for convenience 
the variable ConnSet is assigned to the set of connections in 
SPT that i) match subnet (PA) and ii) have the property that 
it has a pointer exactly matching the address in the variable 
FRM_member. Now it's possible this set could be empty. 
Step (5) asks whether the Conn Set is empty. If the answer 
is yes, then go to Step (10), which asks whether there is a 
connection of SPT matching Subnet (PA) with just a single 
pointer to PA. If the answer is "no" go to Step (9) and add 
a new connection with subnet Subnet (PA) and with a single 
pointer to PA. Then go to Step (11) to determine if the last 
frame member has been reached. If not, continue in the loop, 
going to Step (12) to set Frm__member to the next element, 
and continue processing. On the other hand, if the answer is 
"yes" at step (U), then processing of PA is finished. Then go 
to Step (F), which is in the original FIG. 31, to process the 
next port address. Now, on the other hand if the answer is 
"yes" at Step (10) i.e., there a connection in SPT matching 
subnet (PA) with just pointer to PA, then go to Step (11) and 
continue in the loop over Frame members. 

Now referring again to Step (5), if ConnSet is not empty 
then we go to Step (6), which asks whether there is a 
member of ConnSet having just one pointer. If the answer is 
"yes", add a pointer to PA to this member, (step (7)), and 
then continue to Step (U) to process the remaining elements 
of FRM. If the answer is "no** then go to step (8), and create 
a new connection whose label is subnet (PA), and under this 
we add two pointers: one to PA and the other to the port 
address corresponding to the address in FRM_member. 

To give a better feel for the flowchart that we obtained 
after grafting in the additional steps to handle multi-point 
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WANs, (FIG. 33) we'll walk through a specific example, the 
one that's intuitively depicted in FIG. 34, whose configu- 
rations appear in FIGS. 38a through 3&f and having an SRO 
as shown in FIG. 37. (FIG. 37 shows only one of the SROs 

5 (for Router Rl)). We do not include the SROs for Router R2 
through R4 because the process of going from a config file 
to a SRO representation for these routers should be evident. 

FIGS. 39a through 39/ provide a detailed example used as 
a walkthrough of the flow chart depicted in FIG. 33. 

10 Starting at FIG. 39a we see reference to Step (1) of the 
flowchart of FIG. 33 where the output, the SPT, is initialized 
to the structure shown opposite Step (1). This is an IP SPT. 
So the protocol is set to IP. In step (2) PA is set to the first 
port address, 11733.41.1 255.255.255.0. At Step (3) the 

15 question is whether subnet (PA), which is 117.33.4.0, is in 
the SPT. In this case it is not because the SPT is empty. Thus, 
go on to Step (4), which adds a new Connection, whose 
subnet is 117.33.4.0, to the SPT. Then go to Step (9), which 
adds a pointer under this subnet to Rl, SO, IP1 (the current 

20 port address). Referring to Step (9) in FIG. 39a, there is 
shown the structure formed by Step (9). After Step (9) go to 
Step (18), which asks whether PA is the last port address. 
The answer here is "no". Processing goes to Stop (19) where 
PA is set to the next port address, 11733.4.2 255 and 

25 255.255.0. After Step (19), go to Step (3), which asks 
whether subnet (PA), (11733.4.0) is in the SPT. The answer 
here is "yes". In FIG. 39£>, there is a continuation of the 
walkthrough continuing from step (3), which answered 
"yes". Thus the current step is Step (5), which asks whether 

30 PA is Frame Relay encapsulated. The answer is "yes". Thus 
go to Step (6) and set the variable FRM to the set of Frame 
Relay map addresses associated with PA's port. In this case 
there are two of them, 11733.4.1 and 11733.4.3. Then go to 
Step (7) and set FRM_jnember to the first address, 

35 117.33.4.1. Then go to Step (8) and set the variable ConnSet 
to the connections in the SPT matching subnet 117.33.4.0 
with a pointer exactly matching the Frame member. In this 
case, ConnSet contains Cbnn[l] because this has the subnet 
11733.4.0 and also has a pointer to R1,S0,IP1 whose 

40 address is 11733.4.1. 

Next, go to to Step (12) which asks whether the Conn__ 
Set is empty. Here it has one element and so the answer is 
"no". Step (15) asks whether there is a member of ConnSet 
having just one pointer. The answer here is "yes" because 

45 Conn [1] only has one pointer. Thus go to Step (16) and add 
a pointer to PA under this connection forming the structure 
shown at (16) in FIG. 39fe. Then gp from Step (16) to Step 
(10) which asks whether the process has reached the last 
member of FRM. In this case "no" because there is one more 

50 element to process. So, the answer at Step (10) is "no". 
Refer now to FIG. 39c. Since the answer to (10) was "no", 
the current step is Step (11), and FRM_member is set to the 
next element of FRM, 11733.43. Then go to Step (8) and 
set ConnSet to the connections matching 11733.4.0 and also 

55 with the pointer exactly matching frame member which is 
11733.43. In this case there are no connections meeting the 
second criteria. So Step (13) asks whether there is a con- 
nection matching subnet (PA) with a pointer to PA in SPT? 
The answer here is "no". Go to Step (14) and add a new 

60 connection with subnet 117.33.4.0 to SPT under it, a pointer 
to PA. The resulting structural addition to the SPT is shown 
in the diagram at reference numeral (14) in FIG. 39c. Then 
go to Step (10), which asks if the last member of the frame 
set has been processed. The answer here is "yes," and thus 

65 we go on to Step (18) which asks whether the last port 
address has been reached. The answer here is "no" because 
there are more port addresses to process. Go to Step (19) 
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which sets the next port address to 117.33.4.3 and 
255.255.0.0. Move now to FIG. 39d, which is a continuation 
of the walkthrough example. After setting the new port 
address in Step (19), go to Step (3) which asks whether the 
subnet is associated with the new port address (which in this 
case is 117.33.4.0) in the SPT. The answer here is "yes". 
Thus, go to Step (5), which asks whether this Frame Relay 
encapsulated. The answer is "yes," and thus processing goes 
to Step (6), which sets the variable FRM to the set of frame 
maps associated with this PA port. In this case, PA refers to 
Router R3*s SO port, which has two Frame Relay addresses, 
117.33.4.1 and 117.33.4.2. Go to Step (7) and set FRM_ 
member to the first element of the frame set, 117.33.4.1. 
Next in Step (8), compute the ConnSet by looking for 
connections that match subnet (PA), 117.33.4.0, and ones 
that also have a pointer exactly matching the frame member. 
In this case one element is found, Conn[l], because its first 
pointer Rl, SO, IP1 has the address 117.33.4.1. So the 
ConnSet has a single element. Go to Step (12) and ask 
whether ConnSet is empty. The answer here is "no". Go to 
Step (15), which asks whether there is a member of ConnSet 
having just one pointer. The answer here is "no" because 
Conn[l] has two pointers under it. Go on to* Step (17) and 
add a new connection with subnet 117.33.4.0, and under it 
add a pointer to both PA which is R3, SO, IP1 and to the port 
address corresponding to the FRM_member, which is Rl, 
SO, IP1. Looking in FIG. 39d, reference numeral (17), 
indicates structure add to the SPT upon completing Step 
(17). 

Refer now to FIG. 39e, which is a continuation of the 
walkthrough. Step (10) asks whether the last member in 
FRM has been processed. The answer here is "no" because 
there is one member left to process, and thus processing goes 
to Step (11), where FRM_jnember is set to this next 
element, 11733.4.2, to the first IP address on R2, SO. Next 
at Step (8), Connections matching 117.33.4.0 with a pointer 
at exactly matching the FRM__member 11733.4.2. In this 
case the ConnSet will have one element which is Conn[2]. 
Thus, the answer at Step (12) is "no", and processing goes 
to Step (15) which answers "yes" since ConnSet has a single 
member. Consequently, processing goes to (16) which adds 
a pointer to PA under this member Conn[2] leading to the 
structure in FIG. 39e adjacent to reference numeral (16). 
After Step (16), processing goes to Step (10) which asks if 

the last FRM member in FRM has been processed. The 

answer here is "yes". Hence go to Step (18), which asks if 
the last port address has been processed. The answer here is 
"no". There is still one more port address to process. Step 
(19) sets variable PA to the next port address which is 
11733.4.4 and 255.255.0. Next, Step (3). At step (3), the 
answer is "yes" since subnet (PA) which equals 117.33.4.0, 
is in the SPT We then go to Step (5), which answers "yes" 
since PA is frame relay encapsulated. 

The walkthrough example now continues with FIG. 39/. 
Step (6) sets FRM equal to the Frame relay maps. In this 
case it is a set having one element, 11733.4.1. Go to Step (7) 
where the FRM_member is set to the first element, which 
is the only element, 11733.4.1. In Step (8) look for the 
connections matching subnet 11733.4.0 with a pointer 
exactly matching FRM_member. In this case two matching 
elements are found: Conn[l] and Conn[3]. Step (12) asks 
whether the set is empty. The answer here is "no" because 
it has two elements. Go to Step (15), which asks whether 
there is a member of ConnSet having just one pointer. The 
answer here is "no". The two elements both have two 
pointers. Go to Step (17) which adds a new connection with 
subnet 117.33.4.0 and a pointer to PA, which is R4, SO, IP1, 
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and also to the port address corresponding to FRM 

member, which is Rl, SO, I PI resulting in the SPT structure 
shown adjacent to reference numeral (17) in FIG. 39/. Go to 
Step (10) which asks if the last member of FRM has been 

5 reached. The answer here is "yes". Go to Step (18) which 
then leads to termination of the procedure since the last port 
address has been processed. 

Next we shall discuss the construction of the MPT, which 
stands for the Multiple Protocol Topology. Referring to FIG. 

10 lb, the MPT is constructed in Step (4). The MPT is con- 
structed from the set of SPTs. The MPT is as a data structure 
that captures the interrelationships between the different 
Level 3 topologies, each of which is encoded as an SPT. A 
single router's physical port can have multiple Level 3 

15 addresses configured on it with different protocols. When 
there are multiple addresses from different protocols 
assigned to router's ports in the network there is potential for 
logical topologies with incompatible addresses. 

As used herein, "incompatible addresses" means two 

20 level 3 protocols, such as IP and IPX, have assignments to 
port addresses that are inconsistent. An example of a net- 
work with incompatible addresses is shown in FIG. 26, 
which shows a network with mismatched IP and IPX* 
addresses and two IP and IPX connections that would be 

2 5 flagged as being a Mismatch by the process shown in FIG. 
23. The reason that these two connections are in conflict is 
because they overlap by virtue of having the pointer labeled 
(1) (in FIG. 26) refer to the same port as the pointer labeled 
(4) and also having pointers (2) and (5) match. On the other 

30 hand, pointer (3) does not match pointer (6) and thus IP and 
IPX connections are in conflict. Looking at the network in 
FIG. 26, we see that this conflict is important to identify 
because it is caused by mis-addressing Router Rl's Tl port 
with an IP address belonging to subnet 10.10.10.0. The 

35 problem could be corrected by instead putting this address 
on Rl's TO port. 

In the process of building a MPT from a set of SPTs, (one 
for each Level 3 protocol running on the network), certain 
existing conflicts between the SPTs can be identified through 

40 certain integrity checks. Although networks may be able to 
run when their logical topologies have incompatible 
addresses it is a common practice to do, which otherwise 
greatly improves the ability to manage the network. Because 
it is common practice to have logical topologies with 

45 compatible addresses, finding the conflicts between logical 
topologies can be an extremely valuable diagnostic aid that 
can identify addressing errors. As mentioned earlier, it can 
be important to identify addressing errors because they can 
have substantial impact on network operations. An impor- 

50 tant benefit of computing how logical topologies relate is 
that information regarding one logical topology can be used 
to fill in missing information about another logical topology 
once they are synchronized. We will show, later on, an 
example of how information that would be missed by just 

55 looking at the IP topology alone because of a Cisco con- 
figuration command called IP-unnumbered could be filled in 
by using logical topologies from the other protocols such as 
IPX and AppleTalk. The production of the MPT is a unique 
aspect of the invention. The MPT serves to coordinate 

60 topologies from different protocols. 

FIG. 21 provides an illustration of a MPT data structure, 
in attribute form. A MPT structurally looks very similar to an 
SPT. A MPT consists of a list of objects which are called 
Multiple Protocol Connections. In FIG. 21, reference 

65 numeral (1) indicates a first multiple protocol connection 
labeled MpC[l] . This object contains a list of subnets that 
it refers to. Each subnet is from a different protocol. Note 
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also that, for IPX for example, a network number would be connection in MPT. Step (lb) asks whether the IPX con- 
included in the list. So, MpC[l] could have an IP subnet and nection intersects the MPNTR. As used herein, the term 
an IPX network number. A multiple protocol connection "intersect** means "refers to one or more of the same ports." 
object also contains a list of pointers, nor to the port address If the answer is "no**, then Step (Iti) asks whether MPNTR 
on a router, but to the port itself. So, a pointer for a MpC is 5 is the last MpC in the MPT. If the answer is "yes", then all 
identified by simply a router and a port. It does not have the the connections in MPT have been processed, and no 
additional attribute that SPT has which identifies a particular matches or intersections have been found. The process exits 
address within a port. So one could think of a MPT as tying with status: completely no match. If there are more MPCs to 
together router ports and grouping them together in the process, then set the variable MPNTR to the next connection 
different protocol (sub)nets that correspond to each other. 10 in MPT (Step 7) and go back to Step (lb). 

FIG. 22 is a flowchart that computes a process which If at Step (76), an intersection is found between "C" and 

produces a MPT from a set of SPTs denoting the different MPNTR then go to Step (7c) which asks what type of 

logical topologies. In addition, during formation of the MPT intersection relationship is present. Specifically, the question 

the process will also find mismatches between the is whether there is a one to one correspondence between 

topologies, which are put in a mismatch set which is another 15 MPNTR and "C\ That is, do they point to the exact same 

output for this process. Identifying such mismatches is a router ports? If the answer is "yes** then the process exits 

particular integrity check in accordance with the invention. with status: a complete match. If there is not a one-to-one 

Note that although FIG. 22 only handles processing of IP correspondence, then Step (le) asks whether the ports in "C" 

and IPX, the process is easily generalized to handle other refer to a P ro P er subset of me P° rts referred to by MPNTR 

protocols. For example, the same basic process can be used 20 or visa versa - m omcr words, do we have a subset relatioo- 

to process IP, IPX and AppleTalk. shi P ? If answer is "yes" then the procedure exists with 

In Steps (1) and (la), the two outputs of the process, the/ stato: ^ bsct ^'ionship. K the process exits with a 

MPT and Mismatch set arc initialized to empty. The first part mismatch status. 

of the process, which is denoted by Steps (2) through (5), AGS. 24a through 24i, illustrate a walkthrough example 

handles the IP part, and then the rest of the process handles of the flowcharts of FIGS. 22 and 23. The walkthrough 

the IPX part. For the IP part, a relatively simple process is example shown in FIGS. 24a through 24*" uses as input the 

used which essentially just copies the IP structure into the IP SPT "> FIG. 8i and the IPX SPT in FIG. 8j. Recall that 

MPT. Step (2) sets "CT to the first connection in the IP SPT. these SPTs were produced from the SROs in FIGS, la and 

Step (3) adds into MPT a MpC corresponding to this 76. The SROs, in turn represent the router configuration files 

connection. Step (4) asks whether "C is the last IP con- shown in FIGS. 6a and 6b. Recall that FIG. 5 is intended to 

nection in SPT^ If "C" is the last IP connection, then go to be 10 intuitive illustration of the routers in the network. 

Step (6). If "C" is not the last IP Connection, go to Step (5) Referring to FIG. 24a, the diagram shows the state of the 

and set C to the next IP connection and repeat the process. output MPT after Step (1) in FIG. 22 is executed. Reference 

When Step (6) is reached the IP SPT has been "copied" into numeral in FIG. 24 indicates that at Step (la) in FIG. 22, 

the MPT. MisMatch is initialized to empty. Step (2) sets "C" to the first 

Next, the process represented by Steps (6) through (12) IP connection in SPT IP, Conn[l] in FIG. 8/ whose subnet is 

integrates the IPX SPT into the MPT, and also look for 10.30.0.0. Step (3) adds a connection corresponding to "C* 

conflicts. In these Steps, variable "C* is used to iterate over to ^ MPT 1716 2413 shows m e resulting MPT state after 

the IPX connections. Step (6) sets "C" to the first IPX ^ applymg Step (3). Note the simflanty between the structure 

Connection in the IPX SPT. Step (7) asks whether the result m FIG - 24ft and the structure marked as (1) in FIG. 8i. The 

of matching Connection C with the MpCs in the MPT difference's that the pointer in the MPT is Rl E0, rather than 

(which at this point in the process merely reflect the IP SPT R 2 * E0 » IP1 - In other words rather man pointing to a specific 

structure.) address on a port, a connection in a MPT dust points to the 

The result of the match process is one of four states. One 45 port ^ se ^- 

state is a complete match, another one is a mismatch, FIGS. 24a and 246 show the main operation in processing 

connoting a problem, another state is no match at all and a the IP SPT: the pointers in the IP SPT are copied into the 

last state is a subset relationship. If there is a mismatch, go MPT > omitting their address references yielding pointers just 

to Step (9) and add to the mismatch set the conflict between mentioning a router and a port thereby pointing to a higher 

"C and the conflicting member in MPT. Go to Step (11) to 50 Ievel m the SRO structure and being independent of proto- 

determine if C is the last IPX connection. If it is, the process c °l- 

terminates. If not, set "C" to the next IPX connection and go FIG. 24c shows the results after processing the next 

back to Step (7). If there is a complete match in Step (7) then connection, which is Conn[2] (See FIG. Si). The diagram in 

there is an IP connection and an IPX connection that FIG. 24c shows the state of the MPT after Step (3) is 

correspond to the exact same router ports. In that case, go to 55 executed the second time. Once again, note the similarity 

Step (8) which adds a new IPX subnet to the matching MpC. between the structure in FIG. 24c and the first two connec- 

Then go to Step (11), etc. iterating through the loop. On the tions in the structure of FIG. SL 

other hand, if there is no match or if there is a subset FIG. 244 illustrates the state of the MPT after Conn[3] is 

relationship in Step (7), then go to Step (10) where a new processed in Step (3). 

MpC is created by "copying over** the IPX connection "C\ 60 FIG. 24e shows the state of the MPT after the last IP SPT 

Next go to Step (11). If C is the last IPX Connection, then has been processed. 

the process terminates. If not, go to Step (12), and iterate We have now discussed the first part of the process in FIG. 

through the rest of the IPX connections. 22, where the IP SPT is copied over to the MPT. Next, the 

FIG. 23 is a flowchart that provides additional details process iterates through the IPX SPT where an additional 

about Step (7) in FIG. 22. The input for this flowchart is "C", 65 step is performed that looks for matches and mismatches 

which refers to an IPX connection, and the MPT. The FIG. 24/ continues the walkthrough example at Step (6). In 

process starts at Step (7a) where MPNTR is set to the first this part of the flowchart, the variable "C" is set to the 
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connections in the SPT IPX. In Step (6), "C is set to knowing the port addresses and matching them up. So, if a 

Coon[l] in FIG. 8/ which has (sub)net 9C Step (7) deter- port lacks a port address, the process, in a sense, is blocked, 

mines the type of matching relationship between "C" and the The example network of FIG. 28 shall be used to illustrate 

MPT in FIG. 24e. In this case, the result is a complete match. a procedure that accommodates IP-unnumbered. The 

The reason that there is a complete match between the 5 example network with four routers, R3, R4, R5 and R6. 

connection in FIG. 8; (with subnet 9C) and the first con- Router R3 and Router R4 are connected through their FDDI 

nection in the MPT is that they both corresponded to only 1 interfaces to a FDDI ring whose subnet is 20.20.0.0. 

one router port, Rl, E0. As a result, since the answer to Step Router R3 and Router R5 are connected through their Serial 

(7) is a complete match, go to Step (8) which "adds C's 0 interfaces to a serial link, which is explicitly assigned an 

subnet to the matching MpC. The subnet corresponding to lQ IPX network number, but no IP address (because 

" C is 9C. Referring to FIG. 24/ there is shown subnet: 9C" IP-unnumbered is being used). Routers R4 and R6 are 

which has been added under MpC[l]. connected through their serial 0 interfaces with a serial link 

Referring to FIG. 24e, Step (11) asks, whether "C" is the k S iven ™ IPX network ™mber (9C) but no IP address, 

last IPX connection. The answer is "no" because there are New took at the configuration > fitefot^fcmriouteRaiid 

two more IPX connections to process. Step (12) sets C to the 1S w k hat ^ir SROs structures. In FIGS. 29a through 29d we 

* mv ^ r> rvi u • znn q u* u show the four configuration files. Refer to FIG. 29a refer- 

next IPX connecuon, Conn[2] as shown in FIG. 8;, which ^ * ^ Serial ^ ^ 

has subnet 7A- Step (7) then asfe whans the result of Udtl h ^ ^ , p address ^ an addfess and ma&k we 

matching this IPX connection with 'the MPT In this case, it m ^ ip_ unmimbcred <n oIb: The interface 

is found to be an exact match with MpCP]. Now, refer back mentioned in the command, loopback 1, will not be further 

to FIG. 24/, which is the state of the MPT at the time the 20 discussed because it is not relevant to the present discussion, 

matching takes place. The reason that it is an exact match is However, to give a little more background or what a 

that MpC[2] it refers to two router parts, Rl SO and R2 SO. loopback is: while a router has a number of physical 

and so does Conn[2] in FIG. 8;. Because there is an exast interfaces such as serial, FDDI and Ethernet interfaces, the 

match, go to Step (8) and add "C's" subnet (7 A) under user can manually configure as many loopback interfaces as 

MpC[2] yielding the structure in FIG. 24g. Then go to Step 25 he or she wants. These serve, in a sense, as a way of 

(11) which asks whether "C" is the last IPX connection. The addressing a router. If a host wants to reach a router, it needs 

answer is "no w because there is one more IPX Connection to to mention an address on the router's ports. A common 

process. Step (12) "C* is to the next IPX connection, which technique is to supply loopbacks to serve as addresses into 

in FIG. 8; is Conn[3], which has subnet 98. Then go to Step a router; an advantage of a loopback address over the 

(7) which once again finds an exact match. Note that in FIG. 30 address of a physical port, is that a "loopback cannot fail"). 

8/ Conn[3] has a pointer to one router port R2 £0 as does FIGS. 296 through 29d each have IP-unnumbered con- 

MpC[3] as shown in FIG. 24e. Because there is an exact figurations on their respective Serial 0 interfaces. FIGS. 30a 

match, go to Step (8) which adds "C's" (Sub)net 98 under through 3Qrf show the SROs that are produced by parsing 

MpC[3] yielding the structure shown in FIG. 24h. Finally, and filling in the defaults of the configuration files that are 

Step (11) determines that the last IPX connection has been 3S shown in FIGS. 29a through 29d. FIG. 30a shows the SRO 

reached, and the process exists. The resulting competed corresponding to FIG. 29a. It's a straightforward translation. 

MPT is the structure shown in FIG. 24L The only thing to highlight here is the protocol address 

FIG. 25 shows the integration of the example MPT with indicated by numeral (1). Rather than including an address, 

the example SROs. When we presented the MPTs earlier an object type, "Unnumbered" is provided. The structure in 

there were just pointers, here we replace pointers with the 40 FIG. 30a indicates that the router is an IP-unnumbered and 

actual SROs to better illustrate the integrated structure. This points to the loopback LI. Similarly, FIG. 30i> corresponds 

is a novel aspect of the invention, the fact that the object to FIG. 296, FIG. 30c corresponds to FIG. 29c and FIG. 30d 

model does not merely manage isolated routers, but rather corresponds to FIG. 29a*. 

maintain the interrelationships among routers. Specifically, FIG. 27 shows a flow chart that takes as input the MPT 

the MPTs and the SPTs interrelate the SROs. 45 and the SROs it points to, and as a result of processing will 

Note that in FIG. 25 there are two type of links connoting add more items to the MPT to fill in the missing information 

two different relationships, the single links represent a that's missing in the IP SPT due to the use of 

component relationship (for example, the object type MPT IP-unnumbered. 

has MPC components). The double lines represent pointers. FIG. 30e shows the IP and IPX SPTs that would be 

A pointer differs from a component-link in that it links to a 50 produced for the network intuitively shown in FIG. 28 and 

separate object. with routers having the configuration files shown in FIGS. 

As mentioned above, one of the advantages of forming a 29a-29d. Notice that the IP SPT only has a connection for 

MPT is that information from one logical protocol can be the FDDI because only at the FDDI ports are there are 

used to fill in missing information from another logical explicit IP port addresses. At all the serial ports, 

protocol The following figures show how information that is 55 IP-unnumbered is used. The IPX SPT, on the other hand, has 

omitted from the IP SPT could be filled in from another connections associated with the two serial links, 

protocol, such as IPX. Cisco Systems, for example, has a In FIG. 27, Step (1) sets C to the first connection in MPT. 

configuration option called IP-unnumbered, where on a Step (2) asks whether this connection has a non-IP subnet, 

particular router port, rather than explicitly giving it an IP If the answer is "no", then this Connection does not need to 

address, the IP-unnumbered command could be used. One 60 be processed, and the process goes to Step (3) to process the 

advantage of this configuration option is that it helps to next connection in the MPT. If at step (2), the answer is 

conserve the address space. However, a problematic rami- "yes", then go to Step (5) and determine whether C has all 

fication of using IP-unnumbered is that since a port config- the pointers associated with ports that have IP-unnumbered 

ured with IP-unnumbered does not have its own address, it address. If the answer is "no", then continue at step (3) and 

cannot be readily matched up to the other router ports. 65 process the next connection in the MPT. If the answer is 

Remember that in FIG. 4, which shows how to produce the "yes", then add to connection IP a new subnet labeled 

SPTs, a critical aspect of the SPT formation process is "IP-unnumbered." 
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FIG. 30/ shows the MPT that would be produced after 
performing the MPT construction algorithm, shown in FIG. 
22, and then applying the algorithm for handling missing 
information due to IP unnumbered, shown in FIG. 27. 
Before the IP-unnumbered processing takes place, the MPT 5 
would look like FIG. 30f with the exception that connection 
MPC[1] would only have a single subnet 9c, and not 
"IP-unnumbered" in the subnet list; similarly MPC[2] would 
only have a single subnet 86, and not "IP-unnumbered" in 
the subnet list. The IP-unnumbered subnets shown at points 10 
(1) and (2) in FIG. 30f are added during execution of the "IP 
unnumbered processing algorithm (FIG. 27). The reason that 
"subnet: IP-unnumbered" is added under MPC[1] is the 
presence of the IPX connection between ports R3, SO and 
R5, SO and the fact that both of these ports are configured for 1S 
IP-unnumbered. Similarly, the reason that "subnet: 
IP-unnumbered" is added under MPC[s]is the presence of 
the IPX connection between ports R4, SO and R6, SO and the 
fact that both of these ports are configured for 
IP-unnumbered. 2 o 

FIG. 40 is a flow chart that describes the process for 
finding mismatched bandwidth statements and mismatched 
• delay statements. (Note: this is a non -routing integrity 
check; see FIG. Id). On each port in a router, a bandwidth 
and delay statement is either explicitly or implicitly config- 2 s 
ured. These are used by both the IGRP and EIGRP routing 
protocols to compute the "cost" of a routing path. The 
process illustrated by flowchart in FIG. 40 looks for 
conflicts, where two adjacent router ports are configured 
with different bandwidth and/or delay metrics, which may or 30 
may not be a problem. Because mismatching may be inad- 
vertent and detrimental to the network operation, it is 
valuable integrity check information to present to the user. 

The input of this procedure is the SPT^ and the SRO's 
that it points to. The output is a violation set which is 35 
initialized to empty in Step (1). In Step (2), the variable C 
is set to the first connection in the SPT /P . The process 
iterates through all the connections in the SPT/p. Step (3), 
asks whether there are two or more pointers in C (recall 
these are pointers to port addresses) associated with ports 40 
having bandwidth or delay that are unequal. If the answer is 
"yes", go to Step (4) and add the ports in C with a conflicting 
bandwidth or delay to the violation set. Then go to Step (5), 
which asks whether C is the last connection. If it is, the 
procedure terminates. If not, go back to Step (3). If in Step 45 
(3) the answer is "no conflict", go to Step (5), and process 
the next connection in the SPT/p. 

FIG. 41 provides a flow chart depicting process for 
performing another type of non-routing integrity check, 
(FIG. 2) which looks for static routes configured on the 50 
router that point to routers that do not exist in the network 
being analyzed. This may or may not be a problem. It is a 
problem in the case that the static route's next hop address 
is incorrectly specified; in which case, it will not match an 
existing router. On the other hand it might point to a router 55 
outside the domain being analyzed; in which case, the user 
could discount the integrity check. Let us go step by step 
through the flow chart. The input to this flow chart is the set 
of SROs spanning the network. The output is a violation list 
which in Step (1) is initialized to "empty". The process steps 60 
through all the routers and all the static routes configured. 
Step (2) sets ST to the first static route in the list of routers. 
Step (3) asks whether there is a router with an IP port address 
that matches the static route's next hop address. To deter- 
mine this, the procedure searches through all the SROs. If no 65 
match is found, then add to the violation list, a pointer to this 
static route object, meaning that this static route refers to a 
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next-hop router that is not in the domain of analysis. Step (5) 
asks whether ST is the last static route in the list of routers. 
If the answer is "yes", the process terminates. If the answer 
is "no", ST is set to the next static route and process repeats. 
If the answer to Step (3) is "yes", then the address in the 
static route is within the set of routers, and the procedure 
goes to Step (5) to process the next static route if it exists. 

FIG. 42 describes another non-routing table integrity 
check (See FIG. Id.) This integrity check is responsible for 
looking at all the routers* access lists to find problems within 
an access list. An access list is a set of patterns used to filter 
traffic going into and coming out of a router. Given a 
destination to filter, an access list will be processed starting 
at its first element. If the destination matches this first 
element, then the router looks at the action associated with 
the element; if its a "permit", the destination gets through; 
if its a "deny", the destination is filtered. If the first element 
does not match, the router goes on to the next element and 
looks for a match. If processing get to the end of the access 
list (and thus there's no match) the destination is filtered. 
The checks that are depicted in FIG. 42 look at an access list 
to see if there are two or more elements in the access list 
where the earlier one is more general than the later one. If 
that is the case, the latter one will never be reached. This 
relation is called a "subsumption relation". The high severity 
error occurs when the two access elements in the subsump- 
tion relation have different actions: one says "permit" and 
the other says "deny". The less severe integrity check occurs 
when the access list elements in the subsumption relation 
refer to the same action. In this latter case, its an issue of 
efficiency, in the first case, it's probably a problem where the 
user didn't realize that processing would not reach this more 
specific entry later in the list. 

FIG. 42 illustrates how the process finds subsumption 
problems in the access lists of the routers The input to this 
flow chart is the list of SROs and the output is a violation list 
which has the access list element pairs that are in violation. 
Step 1 of FIG. 42 sets the violation list to "empty". Step (2) 
sets R to the first SRO, that is, to the first router in the list 
of routers. Step (3) asks whether R has one or more access 
lists. If the answer is "no" then there is no need to process 
this router and the process moves to Step (4) which asks 
whether the last router has been reached. If so, the process 
terminates. If not, Step (5) is reached which sets R to the 
next SRO and then continues at Step (3). If in Step (3), router 
(R) has an access list, then set a variable Acc to the first 
access list in R Step (6). 

(A router can have one or many access lists.) Step (7) asks 
whether the access list has more than one element. If it only 
has one element, then there's no processing to do because 
the algorithm is looking for conflicts between two elements. 
So if the answer is "no", move to Step (8), which asks 
whether Acc is the last access list in R. If the answer is "yes", 
then go to Step (4) and process the next router. If the answer 
is "no", then set the variable Acc to the next access list in 
router (R) and then process this access list. If the answer to 
Step (7) is "yes", that is, the access list pointed to by Acc has 
more than one element, then in Step (10) set AcEL which 
will be a pointer to an access element, to the second element 
in Acc. Step (11) asks whether there is any element in the 
access list Acc before AcEL which is equal to or more 
general than AcEL. If this is the case, then conflicts have 
been located. Go to Step (12) where these conflicts are 
placed in the violation list. If this is not the case then at Step 
(13), ask whether the last element in Acc has been reached. 
If the last element in Acc has been reached, then move onto 
Step (8) which processes the next access list in Router R (if 
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it exists). If the answer is "no" at Step (13), then Step (14) 
sets AcEL to the next element in the access list, and the 
process continues processing this access-list element. 

Each router typically has a routing table for each level 3 
protocol. A routing table is responsible for determining the 
"next hop" a packet of data must take along the way from its 
source to its destination. The "next hop" refers to the next 
adjacent router along the "path" through the network that the 
packet(s) will take en route to its ultimate destination. A 
routing table consists of a set of elements, each having a 
destination to match against and a "next hop" specification. 
When a packet enters a router, the router looks in its routing 
table to find a matching element If a match is found, then 
this element indicates the next hop (Note: there could be 
more than one next hop, meaning that there are multiple 
choices). It is possible that for a particular destination no 
route is in the routing table. If that is the case, the router 
looks for what is called a gateway of last resort which might 
or might not beset. If it is not set, then packet being matched 
is dropped by the router. If a gateway of last resort is set, it 
will be handled like any other routing table element, which 
the router will use as ^a defined "next hop". 

FIG. 44 shows, in attribute form, a Routing Table Object. 
For each Level 3 protocol, each router will have a Routing 
T^ble Object. In the first field of the Routing Table Object is 
the Protocol attribute, which is set to IP, IPX, APPLETALK, 
etc. In the second field is a pointer which is either empty or 
references a gateway of last resort (which is a Routing Table 
Element object described below). The last high-level 
attribute, which contains the bulk of this object, is a set of 
routing table elements. Each one of these mentions a des- 
tination and if this destination matches, where to go next. 

In FIG. 44, reference numeral (1) refers to routing table 
element EL[1], which includes a destination. The different 
protocols have different ways of describing the destination. 
For IP, a destination is given by an address and a mask. For 
example, consider a destination with an address being 
10.10.0.0 and a mask being 255.255.0.0. In this context 255 
in the mask means pay attention to the corresponding octet, 
0 means ignore the corresponding octet. So for example, 
10.10.0.0 255.2550.0 would match anything that starts with 
10.10 and any other setting of the last two octets. In general 
mask Octets can be any number from 0 to 255 and "match- 
ing" is decided by applying the mask using Bit-wise AND. 

The second part of a routing table is an attribute "Cost 
Paths", which can have one or more elements. Each Cost 
Path element (see reference numeral (2) in FIG. 44) contains 
five attributes. First, is Protocol indicating the routing pro- 
tocol that caused the element to be put in the routing table. 
This attribute can have a number of settings. A routing table 
element could be there because it is a directly connected 
interface; it could be there because there was a static route; 
or it could be there because it was learned by a dynamic 
routing protocol such as RIP, IGRPor OSPF, etc. The second 
field, Cost/Administrative distance, is an attribute that is 
used in the case of two or more routes being available. When 
there are two routes, the router tries to determine the best 
route. The Cost/ Admin, distance value is a metric that is 
used for comparison to find the best route. The third field, 
Interface, tells which port/interface to send a matching 
packet out of. The Next Hop pointer will be non-empty if the 
protocol was learned either from a static route or a dynamic 
protocol and this tells what next router to send the packet to. 
Lastly, the field, Interface Conn, refers to a connection in the 
SPT of the corresponding protocol that is attached to the 
interface identified in the third field. 

Recall that cost-paths may have one or more elements. It 
is possible to have a number of equal cost-paths in which 
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case cost -paths will have two or more elements showing the 
different ways the router can route the packet. 

The routing table data structures can be obtained in two 
basic ways; these structures can be obtained by reading the 

5 routing tables from the live routers in the network (the 
process shown in FIG. le) or by computing them, through 
simulation, using the integrated SPT/SRO object model as 
input (the process shown in FIG. If). If IP routing tables are 
being computed then the IP SPT is used; if IPX routing 

10 tables are being computed then the IPX SPT is used, etc. 
An important benefit of computing routing tables, rather 
than observing them, is that a simulation using computed 
routing tables can indicate what happens to the routers under 
hypothetical failure scenarios enabling a pro -active failure 

15 analysis. 

The routing tables being used and computed by the 
invention refer to "steady-state" routing tables. The steady- 
state routing tables are the routing tables that are produced 
once the routing process settles; in a live network, the 

20 routing tables can converge to a new state when network 
devices or router ports change in status (i.e., whether they 
are operational or failed); routing tables can also converge to 
a new state when the configuratfbn of the routers or other 
network devices are changed, new devices are added, or 

25 existing ones removed. By saying that the invention is 
computing steady-state routing tables, we mean to imply 
that the invention is not computing information about the 
convergence process, such as the settling time or the number 
of messages exchanged during convergence. 

30 Focusing on steady-state, rather than also the transient 
states, allows novel efficient techniques to be applied in this 
invention because the invention can "cut to the chase"; this 
is in contrast to the live routers running, for example, the 
periodic distance vector protocols, such as RIP and IGRP, 

35 which must do a lot more cycling before obtaining a 
steady-state. 

The invention's routing table simulation technique draws 
on the published specification of the standardized routing 
algorithms, such as RIP and OSPF, and draws on the 

40 vendors' public specification of their own proprietary rout- 
ing protocols, such as Cisco's IGRP and EIGRP routing 
protocols, as well as the vendors embellishments and slight 
modifications to the standardized routing protocols. 
We separate the part of the invention that models the 

45 published algorithms from the rest of the structure, which 
constitutes the invention's novel contribution, by defining 
the functions below, which capture the published algo- 
rithm's behavior. These functions below are used for all of 
the routing protocols being treated. 

50 SEND(RT_EURP,<Ro,Po>) is a function computable 
from Ro's SRO that returns either null if router Ro cannot 
generate from routing table element RT_EL an update using 
routing protocol BP and send it out interface Po; otherwise 
this function returns the routing table element that router Ro 

55 would send when advertising route RT_EL out interface Po 
using protocol RP. If SEND(RT_EL,RP,<Ro,Po>) is non- 
null, then its destination is either the same as RT_EL's 
destination or more general than RT__EL's destination (in 
which case we say that it refers to a summarized route). 

60 Also, if the value of SEND(RT_ELJ*P,<Ro,Po>) is non- 
null, then the protocol attribute associated this value will be 
RP. If the element RT_EL has its protocol attribute set to RP 
or to Direct Connect (meaning that it refers to a directly 
connected interface), then we say that SEND(RT EL,RP, 

65 <Ro,Po>) refers to natively sending RT_EL; otherwise we 
say that SEND(RT_EL,RP,<Ro,Po>) refers to redistribution 
of RT_EL into protocol RP. 
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The function SEND(RT_EL,RP,<Ro,Po>) embodies the 
routing update 'sending" behavior enabled by the configu- 
ration of protocol RP for router Ro, which is captured by the 
(routing) protocol object in Ro's SRO with Protocol 
attribute set to RP (see FIG., 2 for the placement of this 
object in the SRO and a partial view of a routing protocol 
object). There are many routing protocol configuration com- 
mands that impact what routes can be sent out; for example, 
route filters can be configured for a routing protocol, which 
consist of references to access-lists that indicate which 
destinations a routing protocol can send out. Another 
example is passive inteitces; if protocol RP has a passive 
interface on interface (i.e., port) Po, then this protocol will 
not send any updates out of port Po. 

RECEIVE(RT_EL,RP,<Ro,Po>) is a function comput- 
able from Ro's SRO that returns null if either router Ro is 
not running protocol RP or Ro will filter or otherwise block 
element RT_EL in an update from routing protocol RP 
coming in interface Po; otherwise the function returns the 
routing table element that router Ro will consider putting in 
its routing table when receiving an update from RP contain- 
ing element RT„EL. 

Suppose that RECETVE(RT EL,RP,<Ro,Po>) is non-null 
and returns RT_EL2; in this case RT__EL and RT_EL2 can 
differ in the following ways: i) RT_EL2's and RT_EL's 
costlnfo object's cost/admin, dist attributes typically will 
differ (with RT__EL2's cost/admin, dist typically being 
larger), ii) RT_EL's Interface attribute will be set to the 
name associated with Po, iii) RT_EL's Interface_Conn 
attribute will be set to the SPT connection attached to Po, 
and iv) Next__hop^pointer will be set to the pointer on the 
SPT connection associating with the router sending the 
update (so being more formal would require RECEIVE to 
take as another argument the sending router). 

The function RECEIVE(RT_EURP,<Ro,Po>) embodies 
the routing update "receiving" behavior enabled by the 
configuration of protocol RP on router Ro (if RP happens to 
be enabled on Ro). For example, a configuration option that 
can block the reception of incoming updates is the setting of 
an input route filter. 

COMPARE(tasttnfol,CostInfo2,RP,Ro)— -is a function 
computable from Ro's SRO that returns one of the three 
states: Greater__than, Equal_to, or Less_tban. If cost/ 
admin, distance of Costlnfol is less than that of CostInfo2, 

Less than is returned; if the cost/admin, distance of 

Costlnfol is greater than that of CostInfb2, Greater_than is 
returned; otherwise the two cost/admin, distances are equal 
and Equal is returned. (Note: For simplicity here we are not 
presenting the more general form of SEND and RECEIVE 
used in the invention that is applicable in cases where the 
router sending the update and the one directly receiving it 
are not directly connected, such as can be the case for BGP 
(which can use remote neighbors). The invention general- 
izes SEND and RECEIVE so that, rather than just taking a 
port as an input, it can also take an argument that designates 
the router that is receiving or sending the update). 

FIG. 43 depicts the process the invention uses to compute 
the steady-state routing tables for protocol P (e.g., IP, IPX, 
AppleTalk) given a SPT for protocol P, the SROs it points to, 
and the operational status of each router, each of its ports, 
and each of the connections in the SPT. A routing table is 
computed for each router in the set of SROs given as input. 
The output routing tables are the steady state routing tables 
that would be produced by running all the routing protocols 
that are specified in each routers SRO. The invention's 
algorithm is applicable when there are multiple routing 
protocols running on one or more routers. It also handles 
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redistribution between routing protocols; that is, for 
example, router Rl might learn about a destination through 
RIP and if it is configured to do so can re-advertise this route 
by if redistribution from RIP into IGRP is enabled. Lasdy, 

5 the algorithm handles summarization as embodied by the 
SEND function, which has the property that it returns an 
output routing table element that can have a more general- 
ized routing table element destination than the input element 
(to capture summarization cases). 

10 A novel aspect of the invention is that all routing protocols 
are simulated using a distance vector message passing 
scheme based on incremental updates, similar as to what is 
used by EIGRP. This scheme produces the steady-state 
routing tables that are produced by routing algorithms that 

15 use difference methods during their convergence process, 
such as periodic distance vector (RIP and IGRP), link state 
(OSPF, IS-IS, and NLSP), and BGP. Also, for IP destinations 
for all the protocols take both a 32 bit address and 32 bit 
mask, rather than just a 32 bit destination used by RIP and 

20 IGRP. This treatment provides, although, more general than 
needed for RIP and IGRP are for uniformity in implemen- 
tation across routing protocols. The advantage of treating all 
these type of routing algorithms with one type of scheme is 
that it facilitates a general mechanism for explanation and it 

25 makes incorporating a new routing algorithm into the inven- 
tion much easier to handle. 

In Step (1) of the "routing table simulation algorithm" 
(shown in FIG. 43), each routing table (for protocol P) for 
each router is initialized to empty. In Step (2), for each 

30 operational router Ro, routes (i.e., Routing Table Element 
objects) corresponding to Ro's port addresses (for protocol 
P) on ports that have operational status are put into Ro's 
routing table with Protocol set to Direct Connect (see FIG. 
44, point 2); also each static route configured on Ro (see 

35 point 5 on FIG. 2) that is not associated with a failed port, 
is put in Ro's routing table with Protocol set to Static_to_ 
next__bop (note: there are two types of static routes; static 
routes which mention a next hop address and static routes 
that mention a router interface; although the invention treats 

40 both types, for simplicity in the Patent we just discuss the 
statics to a next hop address). 

In Step (3) the static and directly connected routes are 
advertised. For each operational router Ro, each of its 
routing protocols RP will try to advertise update messages 

45 out its operational ports for the static and directly connected 
routes put in its routing table in Step (2). The function SEND 
is used in this step to determine which routes are permitted 
to be advertised out of what ports (as dictated by each 
router's configuration as captured by its SRO (from which 

so SEND is computable)). 

An update message sent from Router Ro out port Po in 
Step (3) is directed (in the simulation) to the SPT connection 
that is attached to (i.e., points to) router Ros port Po. In Step 
(4), each failed connection drops any message it receives, 

55 while each operational connection passes the message to 
each of the other Router/ports attached to the connection. 

Step (5) refers to the process where for each update that 
an operational router receives, it determines for each routing 
table element in the update whether it should be processed 

60 or discarded. A failed router that receives an update or a 
router that receives an update through a failed port simply 
drops the update. The RECEIVE function is used in Step (5) 
to determine if a router is configured to receive each routing 
table element in an update message. In Step (5), the router 

65 is also computing the new cost/admin, distance to be used 
for a received element, which is typically higher than the one 
it received (this "new cost" computation is embodied in the 
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RECEIVE function); in Step (5) the router also discards any routing loops. It is possible to configure the live routers so 

element where its new cost/admin, distance is greater than that they produce persistent, periodic, or transient routing 

an routing table element already in the routing table with loops for different destinations. Routing loops that result 

matching destination. The function COMPARE is used in after the procedure in FIG. 43 terminates can be of any of 

this step to make this cost/admin, distance comparison. The 5 these three types. By having an integrity check point out all 

output of Step (5) is a set of UPD^JTOJROC sets for each these type of loops, the user can then look at the live routers 

router, capturing the update elements that need further to judge the severity of the problem. Clearly, persistent 

processing. routing loops are the most severe and the transient loops are 

In Step (6), for each router Ro with one or more UPD__ least severe. The severity of periodic routing loops depends 
TO_PROC sets, it will add each member from each one of 10 on the frequency that the routing table destination is in "loop 
these sets and put it in its routing table, replacing any route state" versus a non-loop state and whether the non-loop state 
previously in its routing table having higher cost/admin. results in correct routing or a no route condition. Many 
distance. If the new route being added matches a route times, for periodic routes, the user may not be aware because 
already in the table with equal cost/admin, distance, then the he or she may poll the table while in a good state Thus 
resulting table will have multiple (equal cost routes), is knowing about loops, which can be periodic, is valuable 
Another condition mentioned in Step (5) is not an "exact diagnostic information (note: to be formally strict here, in 
match"; by this we mean that two routes have exact same the real routers there may not be a "steady-state" condition 
destinations, cost/admin distances and in addition match on for some routing destinations, such as those involved in a 
the other attributes, such as Interace (see FIG. 44 point 1) periodic routing loop; for this particular case, our algorithm 
(Notes for simplicity here we just present an algorithm that 20 presents one of the cases, in the steady-state routing tables.) 
allows multiple routes that have equal cost/admin, distance; Another novel aspect of the invention stems form the fact 
this is easily- generalized to handle multiple routes where the that in some cases, the simulation "fleshes out the non- 
costs may* differ, a possibility for example, when using determinism** found in t&e live routers. For example, the 
Cisco's IGRP variance command). actual routers can be configured to keep only up to two 

In Step (7) each UPD_TO_JPROC set is examined to 25 (equal cost paths) for each destination. If there happens to be 

look for and remove any routing table element that when put more than two equal routes, two of them will be arbitrarily 

in is an "equal cost/admin, distance" route, that is a route chosen. In contrast the invention can find all the equal cost 

that matched an existing destination and has equal cost/ paths to a destination D and show them all, reporting "two 

admin, distance. The reason for removing these elements is out of the following X paths will be chosen to destination 

because in the next step these "incremental changes" will be 30 D." 

sent out and it is not necessary to send out an incremental Another contrast between the invention and live routers is 

change corresponding to a new, but equal cost/admin, dis- that the invention exploits the fact that in its simulation 

tance route. model all the routers* models are in the same memory space, 

In Step (8), the "incremental updates**, which are in the as opposed to a live network, where each router has its own 

UP_TO_PROC sets will be advertised both through the 35 memory space. For example, Step (9) in FIG. 43 is a 

native protocol associated with each element in a UPD_ question that could be asked only if the routers where in the 

TO JROC set and by redistribution. The SEND function is same memory space. It is a question that looks at global 

used in this step to determine which advertisements and convergence. 

redistributions are permitted by the configuration. Consider Recall that the processes in accordance with the invention 

an element EL in a UPD_TO_PROC set for router Ro. For 40 have the ability to either import routing tables from the live 

the protocol RP associated with EL, SEND(EL,RP,Ro,Po) routers or to calculate the routing tables based on informa- 

will be non-null only if the router Ro is configured to tion in the SROs and SPT's. In either case, once the routing 

natively send EL (using protocol RP) out Po. For a routing table objects are populated, there are a number of integrity 

protocol RP_X different from El's protocol, SEND(EL, checks that can be applied. To see where in the overall 

RP_X4to,Po) will be non-null only if the router Ro is 45 process of the invention these routing table integrity checks 

configured to redistribute from EL*s protocol to RP_X and are applied, refer to FIG. Ig. 

send it out port Po. Like Step (3), Step (8) will only send Before describing how the particular integrity checks 

updates out operational ports. operate, there are some preliminary concepts that need to be 

Step (9) checks whether any updates are sent in Step (8); discussed. The routing tables, as we alluded to, are used by 

if not then the process terminates; otherwise the algorithm 50 the routers when they receive a packet. When a host wants 

loops back to Step (4) where the new updates are processed. to forward a packet to another destination it will send it to 

FIGS. 43a and 43Z> show grafts onto the algorithm in FIG. its neighboring routers and that router, if it has a routing 

43 for additional processing that efficiently handles loop table element, will send to a next hop router en route to a 

conditions; as an update is passed from router to router, the final destination. So in this process, the routers will send 

update is tagged to produce the list of routers that the update 55 packets of data from hop to hop until they reach the 

has visited. The tagging is done in Step (A) shown in FIG. destination. So in a sense, given a set of routing tables they 

43a, which is inserted between FIG. 43's Steps (3) and (4). implicitly define paths through the network going from a 

Before a router sends out an incremental update, it checks if source to a destination. A concept that we'll define here is the 

the update is in a loop; if it is, then it is dropped. FIG. 436 notion as to whether given a source address and a destination 

shows this process as Step (B), which is inserted between 60 address there is a path that exists throughout the network; 

FIG. 43 *s Step (7) and Step (8). The reason for "cutting off and if there is, what path will be taken; and in a case where 

loops" at this point, rather than earlier, before Step (5) when multiple paths can be taken what are these multiple paths, 

an update first reaches the router, is we want to leave the FIG. 45 shows an example network that shall be used for 

routing tables in a * loop state" so that it can be picked up by explanation. In this example, there are five routers, Rl 

the "Routing Loop** Integrity Check, shown in FIG. 66. 65 through R5, Rl and R2 are connected through an Ethernet 

A novel aspect of the invention's steady-state routing (Con[l]). Rl is connected to R2 through a serial link 

table computation is that it contains a number of kind of (Conn[2]). Router R2 is connected to Router R4 through a 
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serial link Conn[3]. R3 and R4 are connected through an 
Ethernet (Conn[4]). R5 is isolated. It's just connected to an 
Ethernet (Conn[5]). Source Addresses and Destination 
Addresses, SA and DAI are respectively source and desti- 
nation addresses on Conn[l], DA2 is a destination address 
on Conn[4] and DA3 is a destination address on Conn[5]. 
(Note: When we say source and destination address that's an 
arbitrary distinction. We say source address because it's 
used as a source in our example and destination address 
because it's used as a destination in our example.) 

Continuing in FIG. 45, the output for the analysis, which 
given a source address and destination address shall be 
called herein a "Completed Path Set." A Completed Path Set 
(CPS) will be empty if there is no path from SA to DA 
(where SA refers to the source address and DA refers to the 
destination address). If CPS has one element that means that 
there's one path from SA to DA and if it has more than one 
element there's multiple paths between the source and 
destination. For the example network, suppose we are con- 
sidering a CPS (a Completed Path Set,) for a path from 
source address SA to DA2. In this case, there will be two 
paths, one of them that starts at SA and goes to Conn[l], Rl, 
Conn[2], R3, Conn[4] and then gets te the destination DA2. 
The second path starts at SA, goes to Conn[l], R2, Conn[3], 
R4, Conn[4] and then to DA2. If on the other hand, we are 
interested in a CPS where the. source destination is SAand 
the destination address is DAI, (this is a case where the 
source and destination are on the same subnet), there would 
be one path; from SAto Conn[l] to DAI. An example where 
there is no path, is if a packet is to go from SA to DA3. In 
this case, CPS would be represented as an empty set. 

FIGS. 46a-46c depict a flow chart that the invention 
follows to produce a CPS, a completed path set, given a 
source address and a destination address. A novel aspect of 
this procedure is that it identifies multiple paths between 
source and destination and is performed off-line; this is in 
contrast, for example, with Cisco Systems Path Tool, which 
is an on-line tool that only identifies the current path, not all 
the possible ones. An advantage of knowing all the paths is 
that the current one might be working while another possible 
path, which can be chosen at a later time, might have 
problems. The best way to present this is a walkthrough of 
a particular example. Refer now our attention on FIG. 48, 
which is a generalized block diagram of a network very 
similar to the one in FIG. 45, but with an added link, the link 
labeled Conn[5] between Rl and R4. Also, the router R5 we 
included in FIG. 45 is omitted. The reason for including this 
link is to show what happens in the case of routing table 
element with multiple paths. In this example, a CPS will be 
produced in which the source address is SA and the desti- 
nation address is DA. 

The input to the process of FIG. 46 is the SPT for the 
protocol under consideration, so in this case, its an SPTP. 
FIG. 49 shows the SPT^ that corresponds to FIG. 48. 

FIG. 50 shows the IP routing table for router Rl. The 
element labeled EL[1], has destination 10.0.0255.255.0.0. It 
has one cost-path, which corresponds to the fact that it is 
directly connected. Routing table element EL[2] corre- 
sponds to destination 199.28.77.0 255.255.255.0 and this 
again is directly connected and corresponds to interface SO. 
Element EL[3], like elements ELE[2] and element EL[1] 
corresponds to a directly connected interface. Element 
EL[4] is the only element out of the four which corresponds 
to a route that was dynamically learned. This corresponds to 
destination 2020.0.0 255.25500. There are two cost-paths in 
the example, showing that there are two different ways to 
leave the router if a packet matches this element. The Cost 
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Path element on the left indicates it was learned by RIP; it 
has a cost/administrative distance of V120. It's interface is SO. 
The next hop pointer is to router R3, SO and its interface 
connection is Conn[2]; the second cost-path object is also 

5 learned via RIP and has the same administrative distance as 
the first cost -path. This object specifies output interface SI, 
rather than SO. Its next hop pointer is R4, SI and its interface 
connection is Conn[5]. 

FIG. 51 shows an IP routing table object for R2. FIG. 52 

10 shows an IP routing table object for R3 and 52a shows an IP 
routing table for router R4. 

The flow chart in FIGS. 46a-46c shall be described in the 
context of the example by going through the walkthrough in 
conjunction with FIGS. 53a-53/. Starting in FIG. 53a refer 

15 to reference numeral (1), which indicates that in Step (1) of 
the flowchart in FIG. 46a the output produced is the CPS, is 
set to "empty". Step (2) asks whether there is a connection 
in the SPT 7/ > (Note: in this example, P is IP because the 
example looks at a destination address and source which are 

20 both IP). The answer in this case "yes 1 *. If this was not the 
case, that meant that the source and destination were on 
subnets that the object model did not have and consequently 
the analysis could not proceed. If the answer is u yeV*, for 
convenience, at Step 3 the variable SC is set to the connec- 

25 tion in the SPT which matches SA's subnet. So for this 
example SC is set to Conn[l] because SA is direcdy con- 
nected to the Ethernet labeled Conn[l]. Step (4) sets DC 
(which is a variable referring to the destination's Conn) to 
the subnet matching DA; in this case it is Conn[4] because 

30 DA is directly connected to Conn[4]. Step (5) asks whether 
SC equals DC. In other words, are the source and destination 
on the same subnet? If that is the case, go to Step (6) and 
return a CPS with one element where the path is from SA, 
to the shared connection, to DA, a very simple path. If the 

35 answer is "no", which is the case in this example, go to Step 
(7) (labeled on FIG. 46b) and initialize a variable called APS 
(for "active path set") to the path that is being constructed. 
In this case, there are two paths in progress. The first one 
starts at SA, goes to Conn[l] and to router Rl, and the 

40 second one goes from SA to Connfl] to router R2. In 
general, at Step (7), the procedure puts in as many elements 
as there are routers connected to the source's subnet. 

In FIG. 53a, we show the progress of APS, which are 
paths that are incrementally building. So in this example, we 

45 can see that we have two paths shown by the dotted lines that 
both start at SA and one that ends at Rl and the other that 
ends at R2. As the process proceeds, it will be picking one 
of the elements in this set to extend by a hop and then puts 
it back in APS unless it gets to its destination the router that 

50 drops the packet or is involved in a routing loop. 

Now refer to FIG. $3b, and more specifically to the 
reference therein to Step (8) (from the flowchart in FIG. 
46£>), which asks whether there are any elements (active 
paths) in APS. If it's "empty", the process terminates. If it 

55 is not empty, then proceed to Step (9). In this case, since the 
ADS has two elements, proceed to Step (9). Step (9) sets the 
variable CP (for "current path") to one of the elements in 
APS and removes this element from APS. In the example, 
CP is set to the first path, which goes from SA to Conn[l] 

60 to router Rl. In Step (10) for convenience we are letting the 
variable, CR (for "current router"), refer to the last router in 
the path CP. In this case, the current router is Rl since there 
is only one router in the path. In Step (11) we ask, "does CR 
appear in the path more than once." This is a check to see if 

65 we are in a routing loop and to protect this procedure from 
being in an infinite loop. If CP refers to a loop, we add CP 
to the set of routing loop paths and proceed by going back 
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to Step (8) to see if there are any more paths to process in 
APS. If there is no loop, we go to Step (12) where we set a 
variable called CPO, standing for the Cost Path Objects, to 
the set of Cost Path objects associated with a routing table 
element that matches the destination address in the current 5 
routers routing table for the applicable protocol; IP in this 
case. If there are no elements matching DA and no gateway 
of last resort, CPO is set to null. 

The bottom of FIG. 53£> shows the cost paths that is set to 
CPO in Step (12). These are the two cost paths that are 10 
circled, the ones that are under element EL[4]. The details of 
how Step (12) is executed are depicted in the flowchart in 
FIG. 47. In FIG. 47, the input is a routing table (the routing 
table for the router and protocol under consideration — 
Router Rl and protocol IP in this example) and DA which is 
refers to the destination address. In our example, the desti- 
nation address is 20.20.1.9. The output is the CPO, in other 
words a set of cost path objects that match the element DA. 
If there is no match, CPO will be empty. 

Let's walk through this flowchart. In Step (1) it asks are 20 
there any elements in the routing table that belong to the 
same -major net as DA. For example, the major net that is 
assdciated with 20.20.0.0 is 200.0.0. (It's a Class A network 
address as opposed to being a Class B or Class C address). 
See, Martin, James, "Internet Address Formats", Local Area 25 
Networks Architectures and Implementations, pp. 439-440, 
PTR Prentice Hall, 1994. In Step (3) of FIG. 47, we set EL 
to the element in the routing table belonging to the desti- 
nation's major net having the most specific mask. The most 
specific mask is the one with the most 255s on the left. In 30 
this case, there is only one element in the routing table 
shown in FIG. 53Z> belonging to net 20.0.0.0 and that is 
element EL [4]. Proceeding to Step (4) we ask, "does this 
element match the destination address?" We look at the 
destination in element EL[4] and we see the destination is 35 
20.20.0.0 with mask 255.255.0.0. That means we are look-' 
ing for any destination that starts 20.20 and don't care about 
the last two octets. In our example this matches. So the 
answer at Step (4) is "yes" and the procedure exits, returning 
this element's cost path set which are the two circled cost 40 
paths in FIG. 53b as output. If it didn't match, we would go 
to Step (5) and see if there are any other elements belonging 
to DA's major network which have a more general mask and 
then go back to Step (4) and try to apply the match. If the 
answer to Step (5) is "no" then we go to Step (2), which asks 45 
the question, "is there a gateway of last resort?" If it is, we 
return the CPO associated with it; if not, we return saying the 
CPO is empty. Also, we should note that in Step (1) if there 
are no matching elements in the routing table that belong to 
the same major net as DA, we go to Step (2) and look for 50 
gateway of last resort and return the CPO associated with it, 
if it is found; otherwise an empty CPO is returned. So in 
general, this procedure iterating, looking for the most spe- 
cific match; if one is found, its CPO is returned, If we don't 
find any matches then we return the gateway of last resort's 55 
CPO if it exists. 

Let's continue the walkthrough at FIG. 53c. To set the 
context, we had reached Step (12) as shown in 536, which 
identified the CPO as being the circled items; in other words, 
the items under element EL[4] in FIG. 53b, In Step (13), we 60 
ask the question, "is the CPO empty?" In this case, since 
there are two elements, the answer is "no" and we go onto 
Step (14). If it were the case that the CPO were "empty", 
meaning that there are no routes in the current router that 
match the destination address, then we are in a sense 65 
discarding this active path and going back to Step (8) to see 
if there are any more active paths to process. In our case, as 
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we said, there was a match, so we go on to Step (14). In Step 
(14) and (15) we take one of the elements of the CPO, 
remove it, and set EL to the CPO we're processing. In this 
case, L is set to the CPO as depicted in FIG. 53c, one CPO 
who's interface is set to SO. We next go to Step (16) which 
asks, "does the destination connection (DC) match the EL's 
connection?" In other words, "are we pointed to the interface 
attached to the media on which the destination is con- 
nected?"; in this case, the answer is "no" because the 
destination connection is Conn[4], but the connection asso- 
ciated with EL is Conn[2]. So the answer at Step (16) is 
"No" and we go onto Step (17). In (17), the current path is 
extended with the element's Conn[2] (EL's interface Conn) 
and the next hop router R3 and put back in the set of active 
paths APS. The diagram in FIG. 53a pictorially shows the 
paths being developed that currently are in APS. 

The walkthrough continues at FIG. S3d; after processing 
Step (17), we go back to Step (13) and see if there is 
(another) cost path object to process. In our example, since 
there was two paths out of the router associated with the 
matching routing table element, there is another cost path 
object to process. In FIG. 53d 9 in the items marked (14) (15) 
we see that CPO fe set to the cost path object who with 
interface is set to SI. We then go to (16) and ask the 
question, "does the connection associated with CPO, which 
in this case is Conn[5], match the destination connection 
Conn[4]. The answer is "No"; we haven't gotten to the 
destination connection. So we go back to Step (17) and add 
a new path to the APS. In this case it is the path that starts 
from SA to Conn[l] to Rl and this time rather than going out 
SO, we go out SI to Conn[5] to Router R4. The diagram in 
53d depicts the three paths under construction that are on the 
APS after we execute Step (17). 

The walkthrough continues at FIG. 53e. After processing 
Step (17) we go back to Step (13) and ask "is the CPO 
empty?" This time the answer is "yes, it is empty", so then 
we go to Steps 8 and 9 which refer to picking one element 
from the APS, if it is not empty, and seeing if we could add 
another hop to it in trying to reach the destination. So after 
going to Step (8) and getting the answer that APS is not 
empty, we go to Step (9) where we set CP to one of the 
elements in the APS. In this case we set it to the path labeled 
Path A in diagram 53d. Step 10 mentioned in FIG. 53e refers 
to setting CR to the last router in the current path, R4. We 
then go to Step (12), which looks through R4s IP routing 
table for a match to destination address DA. In this case, a 
matching element is found with a CPO that is depicted right 
after Steps (14) and (15) in FIG. 53e. This CPO is a directly 
connected CPO, which means that the matching destination, 
which is Subnet 20.20.0.0 is directly connected. CPO's 
interface is set to E0, (Ethernet 0), since it is directly 
connected it does not have a next-hop pointer and associated 
connections, Conn[4], We then go to (16) which asks the 
questions, "does the destination's connection, which is Conn 
[4], match the one on the CPO that we are processing? The 
answer here is 'yes". So, after Step (16) we go to Step (18) 
which is the first time in this example, we have added to the 
CPS; thus, we have reached the destination; the path that 
gets added to the CPS is one that goes from SA to Conn[l] 
to Router Rl to Conn[5] to Router R4, out Conn[4] to the 
destination address. 

After Step (18) processing goes to Step (13), which 
returns "yes" since there are no more cost path objects to 
process; consequently, the algorithm goes to Step (8). At 
Step (8), the APS has the two paths shown in FIG. 53/. This 
processing of elements in the APS repeats itself; the end 
result will be that the CPS has 3 elements which are shown 



04/21/2003, EAST Version: 1.03.0002 



US 6,393,486 Bl 

49 50 

in the computer form at the bottom of FIG. 53/ and shown is connected to R5 that is pointed to by Conn[2]. Given this 

in tbe diagram in the middle of FIG. 53/, the paths are from input port, we ask, "does this input port have an access list 

SA to Conn[l] to Rl to Connp] to R3 to Conn[4] to DA; for the protocol under consideration?" So for our last 

from SA to C6nn[l] to Rl to Conn[5] to R4 to Conn[4] to example, it would be IP. If the answer is "no", we proceed 

DA, and from SA to Conn[l] to R2 to Conn[3] to R4 to 5 as we did in the earlier example and go to Step (12). If the 

Conn[4] to DA. answer is "yes", then we ask at Step C, does the matching 

One of the complications that we have to take into account access list block tbe destination address (DA). If the answer 

in constructing the CPS is that the routers might have both is "no" (it doesn't block it), the packet gets through and 

input and output access lists. These, as we described before, proceed as normal and go on to Step (12). If it does block 

are filters that can block traffic coming into the router (an 10 the packet then we go to Step (8) in 466, which effectively 

input port filter) or going out of the router (an output port means ignore the path being processed because we took it 

filter). If the procedure runs into an access list that blocks the out of the APS; that is, by just going right to Step (8), we are 

path being constructed, then it will not put it into CPS. dropping this path and going to the next one. 

FIG. 54 shows, in attribute form, an access list. An access FIG. 57 shows the modification we make to the flowchart 

list is indexed with a Number as an identifier. Access lists are 15 in FIGS. 46a through 46c, to handle the complication of 

maintained on the router and since the same access list may encountering output access lists. This process is integrated in 

be used on a variety of ports, each port refers to it's at Step (15) in FIG. 46c. Setting context, after the point that 

associated access list by the identifier (Number), rather than we are processing an active path, we identify the current 

redundantly storing the whole access list. The main part of router; we then look to see if there is a matching element in 

an access list is its element objects. Access lists are pro- 20 its routing table that matches the destination address. If that 

cessed by going from the first element down to the next is the case, then we set CPO to the set which shows how to 

element looking for a match, and if there is a match and the get out the router. Then we set EL to the, one of these 

matching element has a permit action, the packet being elements. Step (15) is at •the state where we have a path 

matched gets through. If the matching element then has a (given by EL) out of the router. EL identifies a particular 

"deny" action the matching packet does not get through. If 25 port, so in Step (A) we set output to the port mentioned by 

all the elements in an access list is reached and no match is EL. Then we ask the question in Step (B), "does the output 

found, then the packet is blocked. What "matching" means port have an access list for protocol P?" If the answer is 

depends on the protocol. For IP, the conditions for a match "no", we proceed, doing nothing, and go to Step (16); if the 

are as follows. For example, consider an element with the answer is "yes" we try to match the destination address 

address set to 10.0.0.0 and the mask set to 0.255.255.255: 30 against the access list. If the answer is that it doesn't block 

For an access list element, 0 means consider the correspond- it, we proceed as normal and go to Step (16), if the answer 

ing octet, while 255 means ignore it; so this pattern would is it does block, then we go straight to Step (13), which has 

match anything that starts with Octet 10 and match it me effect of rejecting the path out of the current router given 

regardless of what the last 3 octets are. Similarly, if the by EL. So for example, if you found a matching element 

access list's address and mask were 10.20.0.0 and 0.0.25.25 35 with two ways out of the router, and both of them have 

respectively, this pattern would match anything that starts access lists that block it, then we will drop all paths for the 

with a 10.20 regardless of the last 2 octets. destination DA that go into the router. 

FIG. 55 presents the flow chart that the invention follows Note that although an example has been provided in 

to see if the addresses matches an access list Accl. In Step which matching takes place on destination address, match- 

(1) , we set EL to the first element in the access list. In Step 40 ing can take place on other values as well. For example, as 

(2) we ask, "does the address (addr) match the EL/s address, alternatives, matching can occur on the source address, the 
given the elements mask. If the answer is "no**, we go to Step ports associated with a TCP packet, etc. So there are many 
(4) where we ask, is this the last element? If this is the case conditions that can be applied and tested during the filtering, 
the process terminates saying that the status is "blocked". If For the sake of illustration only, matching on the destination 
the answer is no we set EL to the next element in the access 45 address was discussed above. 

list and proceed by going to Step (2). If the answer to Step FIG. 58 depicts a graft to the flow chart for finding 

(2) was "yes", then we ask the question, is the action network paths (FIGS. 46o-c) to handle paths addressed to 

associated with the matching element a "permit" ? If the routers. To set context, at Step (1) in FIG. 46b, the procedure 

answer is "yes*', then the process exits saying the status is is at the stage where it is processing a path in the active path 

"accepting". If the answer is "no", the process exits with 50 set (APS), referred to by CP and has just assigned the 

status blocked. variable CR to the last router in this path. In FIG. 58, 

As we mentioned, a complication that we have to factor processing (for the graft) goes from Step 10 to Step (A), 

into the flowchart in FIG. 46a-46c taking into account the which determines whether the destination address DA 

access lists on both input and output ports. In FIG. 56 we exactly matches any of CR's port addresses. If the answer is 

show how we patch into Flowchart on FIG. 46 the logic that 55 "yes", then the path being processed is one that is addressed 

is need to process input access lists and in FIG. 57 we show to router CR; consequendy, processing moves to Step (B) 

how we further patch this flowchart to take into account where the path [CP;DA] (i.e., the active path, which has 

output access lists. reached router CR, annotated with the destination address 

The process shown in FIG. 56 is put in place starting from DA) is put into CPS, the set of completed paths; next 

Step (11) in FIG. 46b, When we are at Step (7) in FIG. 46b, 60 processing goes to Step (8), shown in FIG. 46/?, which 

we are at the state where we take a path off the APS list and checks if there is another active path to process, 

set CR to the current router, which is the router last in the If at Step (A), the algorithm determines that the pat is not 

path. After going to Step (11), rather than going directly to addressed to router CR, processing continues as it would 

Step (12) we go to Step (A) as labeled in FIG. 56 and we set have for the non-grafted algorithm; that is, processing 

input port to the port on the current router pointed to by the 65 moves to Step (11), shown in FIG. 46b. 

connection in the current path right proceeding CR. So for FIG. 59 depicts a variant of the flowchart for finding 

the example you saw in FIG. 46b it would be the port that network paths (FIGS. 46a-c) to handle paths starting at a 
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router. The input to this procedure is a reference to a router specify whether or not they should communicate, since this 

R, a destination address DA, the SPT for the protocol is a organization specific requirement. The integrity checks 

associated with DA, the set of SROs that the SPT points to, prior to this were ones that were applicable regardless of the 

and the routing tables (for the associated protocol) for each organization. These are typically patterns, if found, in the 

of the routers. In Step (A), the output set CPS, for Completed 5 network are problems. For the case of paths, there are some 

Path Set, is initialized to empty and at Step (B), the output examples (i.e. routing table integrity checks) where we have 

RLPS, for Routing Loop Path Set, is set to empty. Step (C) integrity checks that do not require asking the user to supply 

checks whether the destination address has a connection in smm and destinatiorj addresses. By virtue of some of the 

the SPT associated with it; if not, then processing termi- configurations of other options in the router, there are 

nates; otherwise^ep (D) is reached where DC is set to the 1Q ^ a5out routers that must commU nicate. 

connection in SPT that address DA is associated with. At ~ , , t t n # _ ~ 4 ,->■,• 

Step (E), the variable APS, for Active Path Set, is set to be 9™™™^ 10 R&m ™ S ? am R ° Ut " Bndgmg 

a single element denoting a path starting at router R; (RSRB), when routers are configured to encapsulate source 

processing then continues at Step (9), shown in FIG. 46b, route bnd S e &affic ( which 15 inherently OSI Model level 2) 

which is the step in the main algorithm, which chooses a over an IP backbone. To do so, a set of routers are designated 

member of APS to process (that is, to try to extend to the 15 as SRB P eers ^ within each of these routers' configuration 

destination address). Because there is only one element in merc * s a mention of peers that it needs to communicate 

APS, in Step (9), CP is set to that element (i.e., the path with. By design, for example, these routers need to talk to 

being "starting at R"). each other over, for example, a TCP connection. Note the 

We have now described the process of, given a SPT the example in FIG. 60, 61a and 616. This is an example of a 

routing tables, a destination address and a source address, 20 network where we have two routers, router Rl and R6 that 

determining whether there exists one or more paths through are configured as source route bridge peers. Router Rl 

the network. This is basic function that we are going to use mentions the address of router R6 and conversely R6 

in the following section, which describes the routing table mentions an address associated with Rl saying that they are 

integrity checks (FIG. 1). source route bridging peers and that they should talk using 

In the general case, whether two hosts should com muni- 25 TCP. 

cate is an organizational specific need. There is no general Reiterating, the routers communicate with TCP. So by 

rule saying this host should talk to this host. So we are virtue of the configuration you see in FIG. 61a and 616 (or 

introducing here a new type of integrity check where the looking in FIG. 62 where we show the RSRB fragments that 

user supplies an input, namely, the set of source and desti- are found on the SRO's of Rl and R6 respectively) we know 

nation address that should communicate and the set of ones 30 that these routers should be able to communicate. In other 

that should not. Given this set of "connection requirements", words, we know there should be a path from router Rl to 

the invention simply applies the CPS algorithm to find if the router R6 and vice versa. So there should be a path from 

source-destination pairs that should communicate have a 30.50.2.1 to 50.7.8.3, a path from Rl to R6, in both 

CPS with one or more elements and the pairs that should not directions. So without asking the user which hosts, or which 

communicate produce an empty CPS. If the invention is 35 routers should communicate we are able to automatically 

given the connectivity requirement, SA should talk to DA infer connectivity requirements. So the integrity check asso- 

and CPS is computed to be empty, then that is an integrity ciated with source route bridging simply looks at all the 

violation to be presented to the user. Conversely, if there is routers for RSRB peer statements and then applies the CPS 

a requirement that SA should not be able to reach DA, but algorithm for each of the routers that should peer together to 

we find that there is a path, then we present this violation to 40 find out if there is one or more path. If there is no path, for 

the user. a RSRB pair, then an integrity violation is given to the user 

FIG. 65 depicts the process for computing the "User showing you, for example, that Rl and R6 cannot commu- 

Specified Requirements" integrity check; the input to this nicate although they are set up as RSRB peers, 

process is a source address SA, destination address DA, a There are a number of examples of these integrity checks 

TYPE variable, which is set to "Permit" or "Block" and the 45 that the invention includes. Another example stems from the 

routing tables objects for each router in the list of SROs. The use of the routing protocol BGP, which can mention a 

output is the state "OK" or "Violation". If TYPE is set to neighbor router which could be many hops away. In this 

Permit then the output will be OK if and only if one or more case, by virtue of having the configuration mention a 

paths exist from the source SA to the destination DA; neighbor, we come up with a connectivity requirement 

conversely, if TYPE is set to Block then the output will be 50 saying that the router should be able to find a path to the 

OK if and only if no paths exist from the source SA to the neighbor. Another example is the use of static routes that 

destination DA. mention an address that is not directly connected, and could 

In Step (1) of the flowchart (FIG. 65), the procedure calls be many hops away. In this situation we want to make sure 

the subfunction described by tie flowchart in 46a-c, which that there is a one-way path from the router to the address 

determines whether there is a path from a source address to 55 that is mentioned. If there is any cases where we have a static 

a destination address given as input; if there is a path, then route not having this property, a violation is flagged. So, in 

the output CPS, which is a set, will be non-empty (and summary, by virtue of configuration, we are able to infer a 

contain the path(s)). At Step (1), the input to this procedure number of connectivity requirements, and if these connec- 

is SA as the source address and DA as the destination tivity requirements are failed, the user is given a list of the 

address. If the output (CPS) is empty, then there is no path 60 violations. 

and processing moves to Step (2), which returns Violation if FIG. 63 depicts the process for computing the "RSRB/ 

TYPE is Permit and OK otherwise (i.e., when TYPE is set DLSW Peer** integrity check; the input to this process is the 

to Block). If CPS in Step (1) is not empty, then processing SROs and routing tables objects for each router in the list of 

moves to Step (3), which returns OK if TYPE is Permit and SROs. The output is the set Conflicts, which contains 

Violation otherwise. 65 <Router, Remote Peer object>; if <R1 ,P1> is in Conflicts, 

The integrity check just presented above required the user this means that a connection cannot be established from 

to give the pairs of source and destination addresses and router Rl to the address of the remote peer mentioned in PI. 
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In Step (1) of the flowchart in FIG. 63, the output 
Conflicts is initialized as an empty set. At Step (2), the 
variable R is set to the first router in the list of SROs and at 
Step (3), the question is asked whether R has any remote 
DLSW or RSRB peers. If the answer is "no", then process- 
ing moves to Step (4) to determine if there are any more 
routers that need processing; if there are more routers to 
process, then the algorithm goes to Step (5), setting R to the 
next router, and then to Step (3) to process this new router. 
If the answer to Step (3) is "yes" (i.e., router R has DLSW 
and/or RSRB peers), then processing moves to Step (6) 
where variable P is set to the first RSRB or DLSW remote 
peer object in R. 

At Step (7), the procedure calls the sub function described 
by the flowchart in 59, which determines whether there is a 
path from a router given as input to a destination given as 
input; if there is a path, then the output CPS, which is a set, 
will be non-empty (and contain the path(s)). At Step (7), the 
input to this procedure is R as the input router and the 
address mentioned in P as the destination address. If the 
output (CPS) is empty, then there is no path and processing 
moves to Step (8) where the pair consisting of R and P is put 
in the set Conflicts: processing next continues at Step (9), 
which checks whether R has any more RSRB or DLSW 
peers needing processing; if there are more remote peers to 
process, then the algorithm sets P to the next remote peer (at 
Step (10) and then moves to Step (7) to process this new 
peer Now, if at Step (7), the result of computing CPS yields 
a non-empty set (i.e. there is a path from R to P's remote 
address), then processing goes straight to Step (9). 

FIG. 64 depicts the process for computing the "BGP 
Neighbor** integrity check; the input to this process is the 
SROs and routing tables objects for each router in the list of 
SROs. The output is the set Conflicts, which contains 
<Router, BGP Neighbor object>; if <R1,N1> is in Conflicts, 
this means that a connection cannot be established from 
router Rl to the address of the neighbor mentioned in Nl. 

Id Step (1) of the flowchart in FIG. 64, the output 
Conflicts is initialized as an empty set. At Step (2), the 
variable R is set to the first router in the list of SROs and at 
Step (3), the question is asked whether R has A BGP process 
running. If the answer is "no**, then processing moves to 
Step (4) to determine if there are any more routers that need 
processing; if there are more routers to process, then the 
algorithm goes to Step (5), setting R to the next router, and 
then to Step (3) to process this new router. If the answer to 
Step (3) is "yes" (i.e., router R has A BGP processing 
running), then processing moves to Step (6) where variable 
N is set to the first BGP neighbor object in R's BGP object. 

At Step (6a), the invention checks whether N*s address 
refers to a remote (Le., more than 1 hop away router); if it 
does not, this neighbor does not need processing, and the 
algorithm moves to Step (9), which checks whether R has 
any more BGP Neighbor Objects to process; if there are 
more BGP process, then the algorithm sets P to the next 
remote peer (at Step (10) and then moves to Step (7) to 
process this new peer. Now, if at Step (6) it is determined 
that N has a remore address then processing goes to Step (7). 

At Step (7), the procedure calls the subfiinction described 
by the flowchart in 59, which determines whether there is a 
path from a router given as input to a destination given as 
input; At Step (7), the input to this procedure is R as the 
input router and the address mentioned in N as the destina- 
tion address. If the output (CPS) is empty, then there is no 
path and processing moves to Step (8) where the pair 
consisting of R and N is put in the set Conflicts; processing 
next continues at Step (9) to process the next BGP Neighbor 
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object with a remote address (if one exists). Now, if at Step 
(7), the result of computing CPS yields a non-empty set (i.e. 
there is a path from R to Ps remote address), then processing 
goes straight to Step (9). 

5 FIG. 66 shows the inventions process for finding all 
routing loops for a protocol P. The input to this procedure is 
a SPT for protocol P, the list of SROs it points to and the set 
of routing tables for protocol P for each router in the list of 
SROs. The output is the set Routing__Loops which contains 

10 elements of the form <Conn ,Pth> where Conn is a connec- 
tion in the SPT and Pth is a path through the network having 
a routing loop for hosts on connection Conn. 

In Step (1) of the flowchart in diagram 66, the output 
Routing__loops is set to empty. At Step (2), the variable R is 

15 set to the first router in the list of SROs given as input. 
Step (3) checks whether there are any connections in the 
SPT for protocol P not directly attached to R. The reason for 
asking this question is because the algorithm will be trying 
to reach aU connections from each router and there is no 

20 need to consider directly connected ones since they are 
trivially reachable. If the answer to Step (3) is "no" (i.e., all 
connections in SPT are connected to R, the processing 
moves to Step (4), which checks to see if the last router has 
been reached; if so, the process terminates, if not, processing 

25 moves to Step (5) where R is set to the next router (in the list 
of SROs) and the process repeats itself for this new router. 

If the answer to Step (3) is "yes' then processing moves 
to Step (6) where variable C is set to the first connection in 
SPT that is not directly attached to R. Next, at Step (7), there 

30 is a check to see if a routing loop with connection C and 
Router R has already be found (which can happen for 
example, if there was an earlier router processed which in 
going to C went through R and ended in a loop). If a loop 
has already been found, there is no need to process Con- 

35 nection C starting at router R and thus execution continues 
at Step (8); at this, the invention checks whether there are 
any more connections (not directly attached to R) left to 
process; if so, processing goes to Step (9) where C is set to 
the next applicable connection and then processing contin- 

40 ues for this new connection (still using router R as the 
starting point); on the other hand, if the answer to Step (6) 
is "no" (i.e., there are no more connection to process), then 
the procedure goes to Step (4) to see if there are any routers 
left to process. 

45 Now, going back to Step (7); if the answer at this step is 
"no", meaning that a routing loop involving connection C 
and router R has not yet been found, then processing moves 
to Step (1). At Step (10), the procedure calls the subfunction 
described by the flowchart in 59, which determines whether 

50 there is a path from a router given as input to a destination 
address given as input and if not whether there is a routing 
loop; At Step (7), the input to this procedure is R, as the input 
router and C, the destination connection, which is given in 
place of a destination address, (note: It is trivial modification 

55 of FIG. 59 to use a destination connection, rather than a 
destination address, as input because essentially the only 
role of the destination address in the CPS procedure is as a 
handle at getting the destination connection (see Step (D) in 
FIG. 62.)) 

60 The result of the CPS computation at Step (7) will be both 
the CPS output and the routing loop set (RLPS) which will 
be empty if no routing loops are found. If RLPS is empty, 
then no problem has been found, and processing continues 
at Step (8), which checks if there is another connection to 

65 process (starting at router R) If RLPS is not empty, then 
processing goes to Step (11), where all the routing loop paths 
contained in RLPS are added to the output Routing Loops, 
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each annotated with the destination connection that they are 
5 associated with (i.e. the connection C), processing then 
continues at Step (8). 

While particular implementations of a presently preferred 
embodiment of the invention have been disclosed, described 5 
and illustrated in detail, it will be appreciated that various 
modifications to the preferred embodiment can be made 
without departing from the spirit and scope of the invention 
which is defined in the appended claims. 

What is claimed is: 

1. A method of analysis of an actual or planned routed 
computer network comprising: 

producing structured routing device data in electronic 
memory which represents the actual or planned routed 
computer network and in which respective stored level 
three protocol routing device port addresses are asso- 15 
ciated with respective routing device names; 

identifying based upon the structured routing device data 
respective first level three protocol subnets associated 
with respective first level three protocol port addresses, 
wherein identifying includes sequencing through the 20 
structured routing device data to identify respective 
level three port addresses associated with a first level 
three protocol and determining respective first level 
three protocol subnet functions associated with such 



routing device data to identify respective level three 
port addresses associated with a second level three 
protocol and determining respective second level three 
protocol subnet functions associated with such identi- 
fied second level three port addresses in the actual or 
planned routed computer network as represented by the 
structured router data. 

4. The method of claim 2, 

wherein producing first connection information includes 
producing in electronic memory respective first subnet 
information which represents respective identified first 
level three protocol subnets and which provides refer- 
ences between the respective first subnet information to 
associated first level three protocol port addresses in the 
structured routing device data; and 

wherein producing second connection information 
includes producing in electronic memory respective 
second subnet information which represents respective 
identified second level three protocol subnets and 
which provides references between the respective sec- 
ond subnet information and associated second level 
three protocol port addresses in the structured routing 
device data. 

5. The method of claim 2 wherein each of the first and 



identified first level three protocol port addresses in the 25 second protocols is a different one of, IP, IPX and AppleTalk. 



actual or planned routed computer network as repre- 
sented by the structured routing device data; and 
producing first connection information in electronic 
memory indicating respective associations between 
respective identified first level three protocol subnets 
and respective first level three protocol port addresses. 

2. A method of analysis of an actual or planned routed 
computer network comprising: 

producing structured routing device data in electronic 
memory which represents the actual or planned routed 
computer network and in which respective stored level 
three protocol routing device port addresses are asso- 
ciated with respective routing device names; 

identifying based upon the structured routing device data 
respective first level three protocol subnets associated 
with respective first level three protocol port addresses; 

producing first connection information in electronic 
memory indicating respective associations between 
respective identified first level three protocol subnets 
and respective first level three protocol port addresses; 

identifying based upon the structured routing device data 
respective second level three protocol subnets associ- 
ated with respective second level three protocol port 
addresses; and 

producing second connection information in electronic 
memory indicating respective associations between 
respective identified second level three protocol sub- 
nets and respective second level three protocol port 
addresses. 

3. The method of claim 2, 

wherein identifying respective first level three protocol 
subnets includes sequencing through the structured 
routing device data to identify respective level three 
port addresses associated with a first level three proto- 
col and determining respective first level three protocol 
subnet functions associated with such identified first 
level three port addresses in the actual or planned 
routed computer network as represented by the struc- 
tured routing device data; and 

wherein identifying respective second level three protocol 
subnets includes sequencing through the structured 
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6. A method of analysis of an actual or planned routed 
computer network comprising: 

producing structured routing device data in electronic 
memory which represents the actual or planned routed 
computer network and in which respective stored level 
three protocol routing device port addresses are asso- 
ciated with respective routing device names; 

identifying based upon the structured routing device data 
respective first level three protocol subnets associated 
with respective first level three protocol port addresses; 

producing first connection information in electronic 
memory indicating respective associations between 
respective identified first level three protocol subnets 
and respective first level three protocol port addresses; 

identifying based upon the structured routing device data 
respective second level three protocol subnets associ- 
ated with respective second level three protocol port 
addresses; 

producing second connection information in electronic 
memory indicating respective associations between 
respective identified second level three protocol sub- 
nets and respective second level three protocol port 
addresses; 

identifying based upon the structured routing device data 
respective third level three protocol subnets associated 
with respective third level three protocol port 
addresses; and 

producing third connection information in electronic 
memory indicating respective associations between 
respective identified third level three protocol subnets 
and respective third level three protocol port addresses. 

7. The method of claim 6, 

wherein identifying respective first subnets includes 
sequencing through the structured routing device data 
to identify respective level three port addresses asso- 
ciated with a first level three protocol and determining 
respective first level three protocol subnet functions 
associated with such identified first level three protocol 
port addresses in the actual or planned routed computer 
network as represented by the structured routing device 
data; 
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wherein identifying respective second subnets includes 
sequencing through the structured routing device data 
to identify respective level three port addresses asso- 
ciated with a second level three protocol and determin- 
ing respective second level three protocol subnet func- 5 
tions associated with such identified second level three 
protocol port addresses in the actual or planned routed 
computer network as represented by the structured 
routing device data; and 

wherein identifying respective third subnets includes 1Q 
sequencing through the structured routing device data 
to identify respective level three port addresses asso- 
ciated with a third level three protocol and determining 
respective third level three protocol subnet functions 
associated with such identified third level three port 
addresses in the actual or planned routed computer 15 
network as represented by the structured routing device 
data. 

8. The method of claim 6, 

wherein producing first connection information includes 
producing in electronic memory respective first subnet 20 
information which represents respective identified first 
level three protocol subnets and which provides respec- 
tive references between the respective first subnet 
information and associated first level three protocol 
port addresses in the structured routing device data; 25 

wherein producing second connection information 
includes producing in electronic memory respective 
second subnet information which represents respective 
identified second level three protocol subnets and 
which provides respective references between the 30 
respective second subnet information and associated 
second level three protocol port addresses in the struc- 
tured routing device data; and 

wherein producing third connection information includes 
producing in electronic memory respective third subnet 35 
information which represents respective identified third 
level three protocol subnets and which provides respec- 
tive references between the respective third subnet 
information and associated third level three protocol 
port addresses in the structured router data. ^ 

9. The method of claim 6 wherein each of the first, second 
and third protocols is a different one of, IP, IPX and 
AppleTalk. 

10. A method of analysis of an actual or planned routed 
computer network comprising: ^ 

producing structured routing device data in electronic 
memory in which respective stored level three protocol 
routing device port addresses are associated with 
respective routing device names from the actual or 
planned routed computer network; 5Q 

identifying respective first level three protocol subnets 
associated with first level three port addresses in the 
actual or planned routed computer network as repre- 
sented by the structured routing device data; 

identifying respective second level three protocol subnets 55 
associated with second level three port addresses in the 
actual or planned routed computer network as repre- 
sented by the structured routing device data; 

identifying respective third level three protocol subnets 
associated with third level three port addresses in the 60 
actual or planned routed computer network as repre- 
sented by the structured router data; 

producing first subnet information in electronic memory 
representing respective first level three protocol sub- 
nets and references to associated first level three pro- 65 
tocol port addresses in the structured routing device 
data; 



producing second subnet information in electronic 
memory representing respective identified second level 
three protocol subnets and references to associated 
second level three protocol port addresses in the struc- 
tured routing device data; and 

producing third subnet information in electronic memory 
representing respective identified third level three pro- 
tocol subnets and references to associated third level 
three protocol port addresses in the structured routing 
device data. 

11. A method of analysis of an actual or planned routed 
computer network comprising: 

producing structured routing device data in electronic 
memory which corresponds to the actual or planned 
routed computer network and which associates respec- 
tive level three protocol routing device port addresses 
with respective routing device names; 

identifying based upon the structured data multiple 
respective first level three protocol subnets respectively 
associated with respective first level three protocol port 
addresses; 

producing first subnet information in electronic memory 
that represents respective first identified level three 
protocol subnets and that references associated first 
level three protocol port addresses in the structured 
routing device data that respectively belong to respec- 
tive represented first level three protocol subnets; 

identifying based upon the structured routing device data 
multiple respective second level three protocol subnets 
respectively associated with respective second level 
three protocol port addresses; and 

producing second subnet information in electronic 
memory that represents the respective second identified 
level three protocol subnets and that references asso- 
ciated second level three protocol port address in the 
structured routing device data that respectively belong 
to respective represented second level three protocol 
subnets. 

12. The method of claim 11, wherein producing first 
structured subnet information includes producing in elec- 
tronic memory respective stored representations of multiple 
different first level three protocol subnets and producing 
respective links in electronic memory between respective 
first subnet representations and respective associated first 
level three protocol port addresses in the structured routing 
device data; 

wherein producing second structured subnet information 
includes producing in electronic memory respective 
stored representations of multiple different second level 
three protocol subnets and producing respective links in 
electronic memory between respective second subnet 
representations and respective associated second level 
three protocol port addresses in the structured routing 
device data. 

13. A method of analysis of an actual or planned routed 
computer network comprising: 

producing structured routing device data in electronic 
memory which corresponds to the actual or planned 
routed computer network and which associates respec- 
tive level three protocol routing device port addresses 
with respective routing device names; 

identifying based upon the structured data multiple 
respective first level three protocol subnets respectively 
associated with respective first level three protocol port 
addresses; 

producing first subnet infbrmation in electronic memory 
that represents respective first identified level three 
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protocol subnets and that references associated first 
level three protocol port addresses in the structured 
routing device data that respectively belong to respec- 
tive represented first level three protocol subnets; 

identifying based upon the structured routing device data 5 
multiple respective second level three protocol subnets 
respectively associated with respective second level 
three protocol port addresses; 

producing second subnet information in electronic 
memory that represents the respective second identified 10 
level three protocol subnets and that references asso- 
ciated second level three protocol port addresses in the 
structured routing device data that respectively belong 
to respective represented second level three protocol 
subnets; 15 

identifying based upon the structured routing device data 
multiple respective third level three protocol subnets 
respectively associated with respective third level three 
protocol port addresses; and 2Q 

producing third subnet information in electronic memory 
that represents the respective.third identified level three 
protocol subnets and that references associated third 
level three protocol port addresses in the structured 
routing device data that respectively belong to respec- 2 s 
tive represented third level three protocol subnets. 

14. The method of claim 13, wherein producing first 
structured subnet information includes producing in elec- 
tronic memory respective stored representations of multiple 
different first level three protocol subnets and producing 30 
respective links in electronic memory between respective 
first subnet representations and respective associated first 
level three protocol port addresses in the structured routing 
device data; 

wherein producing second structured subnet information 35 
includes producing in electronic memory respective 
stored representations of multiple different second level 
three protocol subnets and producing respective links in 
electronic memory between respective second subnet 
representations and respective associated second level 40 
three protocol port addresses in the structured routing 
device data; 

wherein producing third structured subnet information 
includes producing in electronic memory respective 
stored representations of multiple different third level 4S 
three protocol subnets and producing respective links in 
electronic memory between respective third level three 
protocol subnet representations and respective associ- 
ated third level three protocol port addresses in the 
structured routing device data. 50 

15. A method of analysis of an actual or planned routed 
computer network comprising: 

producing structured routing device data in electronic 
memory which corresponds to the actual or planned 
routed computer network and which associates respec- 55 
tive level three protocol routing device port addresses 
with respective routing device names; 

identifying based upon the structured data multiple 
respective first level three protocol subnets respectively 6Q 
associated with respective first level three protocol port 
addresses; 

producing in electronic memory first subnet information 
which includes respective stored representations of 
multiple different first level three protocol subnets; 65 

producing respective references in electronic memory 
between respective first subnet representations and 
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respective first level three protocol port addresses such 
that such respective references represent respective 
connections between respective routing device ports in 
the actual or planned routed network; 
producing in electronic memory second subnet informa- 
tion which includes respective stored representations of 
multiple different second level three protocol subnets; 
and 

producing respective references in electronic memory 
between respective second subnet representations and 
respective second level three protocol port addresses 
such that such respective references represent respec- 
tive connections between respective routing device 
ports in the actual or planned routed network. 

16. The method of claim 15 further comprising: 
producing in electronic memory third subnet information 

which includes respective stored representations of 
multiple different third level three protocol subnets; and 
producing respective references in electronic memory 
between respective third subnet representations and 
respective third level three protocol port addresses such 
that such respective references represent respective 
connections between respective router gorts in the 
actual or planned routed network. 

17. A method of analyzing a routed computer network, 
comprising the computer-implemented steps of: 

creating and storing structured routing device data in 
electronic memory which represents the routed com- 
puter network and in which stored level three protocol 
routing device port addresses are associated with cor- 
responding routing device names; 

identifying, based upon the structured routing device data, 
one or more first level three protocol subnets that are 
associated with corresponding first level three protocol 
port addresses, by sequencing through the structured 
routing device data to identify level three port 
addresses that are associated with a first level three 
protocol subnet and detennining respective first level 
three protocol subnet functions associated with such 
identified first level three protocol port addresses in the 
routed computer network; and 

creating and storing first connection information in elec- 
tronic memory indicating one or more associations 
between the first level three protocol subnets that have 
been identified and corresponding first level three pro- 
tocol port addresses. 

18. A method as recited in claim 17, further comprising 
the steps of: 

identifying, based upon the structured routing device data, 
one or more second level three protocol subnets that are 
associated with corresponding second level three pro- 
tocol port addresses; and 

creating and storing second connection information in 
electronic memory indicating one or more associations 
between the second level three protocol subnets that 
have been identified and corresponding second level 
three protocol port addresses. 

19. A method as recited in claim 17, wherein the step of 
identifying first level three protocol subnets includes the 
steps of sequencing through the structured routing device 
data to identify one or more level three port addresses that 
are associated with a first level three protocol, and deter- 
mining one or more first level three protocol subnet func- 
tions that are associated with the first level three port 
addresses that are identified. 

20. A method as recited in claim 17, wherein the step of 
identifying second level three protocol subnets includes the 



04/21/2003, EAST Version: 1.03.0002 



US 6,393,486 Bl 



61 



62 



steps of sequencing through the structured routing device 
data to identify one or more level three port addresses that 
are associated with a second level three protocol, and 
determining one or more second level three protocol subnet 
functions that are associated with the first level three port 
addresses that are identified. 

21. A method as recited in claim 17, wherein the step of 
creating and storing first connection information includes 
the step of creating and storing first subnet information that 
represents the first level three protocol subnets that have 
been identified, and that includes one or more references 
between the first subnet information and corresponding first 
level three protocol port addresses in the structured routing 
device data. 

22. A method as recited in claim 17, wherein the step of 
creating and storing second connection information includes 
the step of creating and storing second subnet information 
that represents the second level three protocol subnets that 
have been identified, and that includes one or more refer- 
ences between the second subnet information and corre- 
sponding second level three protocol port addresses in the 
structured routing device data. 

23. A method as recited in claim 17, further comprising 
the steps of: 

identifying, based upon the structured routing device data, 
one or more second level three protocol subnets asso- 
ciated with corresponding second level three protocol 
port addresses; 

creating and storing second connection information in 
electronic memory that indicates one or more associa- 
tions between the second level three protocol subnets 
that have been identified and one or more second level 
three protocol port addresses; 

identifying, based upon the structured routing device data, 
one or more third level three protocol subnets associ- 
ated with corresponding third level three protocol port 
addresses; 

creating and storing third connection information in elec- 
tronic memory that indicates one or more associations 
between the third level three protocol subnets that have 
been identified and one or more third level three 
protocol port addresses. 

24. A method as recited in claim 17, further comprising 
the steps of: 

creating and storing in electronic memory second subnet 
information that includes one or more stored represen- 
tations of one or more different second level three 
protocol subnets; and 

creating and storing references in electronic memory 
between the second subnet representations and corre- 
sponding second level three protocol port addresses, 
wherein the references represent corresponding con- 
nections between routing device ports in the network. 

25. A computer-readable medium carrying one or more 
sequences of instructions for analyzing a routed computer 
network, wherein execution of the one or more sequences of 
instructions by one or more processors causes the one or 
more processors to perform the steps of: 

creating and storing structured routing device data in 
electronic memory which represents the routed com- 
puter network and in which stored level three protocol 
routing device port addresses are associated with cor- 
responding routing device names; 

identifying, based upon the structured routing device data, 
one or more first level three protocol subnets that are 
associated with corresponding first level three protocol 
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port addresses, by sequencing through the structured 
routing device data to identify level three port 
addresses that are associated with a first level three 
protocol subnet and determining respective first level 
three protocol subnet functions associated with such 
identified first level three protocol port addresses in the 
routed computer network; and 
creating and storing first connection information in elec- 
tronic memory indicating one or more associations 
between the first level three protocol subnets that have 
been identified and corresponding first level three pro- 
tocol port addresses. 

26. A computer-readable medium as recited in claim 25, 
further comprising instructions which, when executed by the 
one or more processors, cause the one or more processors to 
carry out the steps of: 

identifying, based upon the structured routing device data, 
one or more second level three protocol subnets that are 
associated with corresponding second level three pro- 
tocol port addresses; and 

creating and storing second connection information in 
electronic memory indicating one or more associations 
between the second level three protocol subnets that 
have been identified and corresponding second level 
three protocol port addresses. 

27. A computer-readable medium as recited in claim 25, 
wherein the instructions for carrying out the steps of iden- 
tifying first level three protocol subnets include instructions 
for carrying out the steps of sequencing through the struc- 
tured routing device data to identify one or more level three 
port addresses that are associated with a first level three 
protocol, and determining one or more first level three 
protocol subnet functions that are associated with the first 
level three port addresses that are identified. 

28. A computer-readable medium as recited in claim 25, 
wherein the instructions for carrying out the steps of iden- 
tifying second level three protocol subnets include instruc- 
tions for carrying out the steps of sequencing through the 
structured routing device data to identify one or more level 
three port addresses that are associated with a second level 
three protocol, and determining one or more second level 
three protocol subnet functions that are associated with the 
first level three port addresses that are identified. 

29. A computer-readable medium as recited in claim 25, 
wherein the instructions for carrying out the step of creating 
and storing first connection information include instructions 
for carrying out the step of creating and storing first subnet 
information that represents the first level three protocol 
subnets that have been identified, and that includes one or 
more references between the first subnet information and 
corresponding first level three protocol port addresses in the 
structured routing device data. 

30. A computer-readable medium as recited in claim 25, 
wherein the instructions for carrying out the step of creating 
and storing second connection information include instruc- 
tions for carrying out the step of creating and storing second 
subnet information that represents the second level three 
protocol subnets that have been identified, and that includes 
one or more references between the second subnet informa- 
tion and corresponding second level three protocol port 
addresses in the structured routing device data. 

31. A computer-readable medium as recited in claim 25, 
further comprising instructions for carrying out the steps of: 

identifying, based upon the structured routing device data, 
one or more second level three protocol subnets asso- 
ciated with corresponding second level three protocol 
port addresses; 
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creating and storing second connection information in 
electronic memory that indicates one or more associa- 
tions between the second level three protocol subnets 
that have been identified and one or more second level 
three protocol port addresses; 5 

identifying, based upon the structured routing device data, 
one or more third level three protocol subnets associ- 
ated with corresponding third level three protocol port 
addresses; 

creating and storing third connection information in elec- 10 
tronic memory that indicates one or more associations 
between the third level three protocol subnets that have 
been identified and one or more third level three 
protocol port addresses. 

32. A computer-readable medium as recited in claim 25, 15 
further comprising instructions for carrying out the steps of: 

creating and storing in electronic memory second subnet 
information that includes one or more stored represen- 
tations of one or more different second level three 2Q 
protocol subnets; and 

creating and storing references in electronic memory 
between the second subnet representations and corre- 
sponding second level three protocol port addresses, 
wherein the references represent corresponding con- 2 s 
nections between routing device ports in the network. 

33. An apparatus for analyzing a routed computer 
network, comprising: 

means for creating and storing structured routing device 
data in electronic memory which represents the routed 30 
computer network and in which stored level three 
protocol routing device port addresses are associated 
with corresponding routing device names; 

means for identifying, based upon the structured routing 
device data, one or more first level three protocol 35 
subnets that are associated with corresponding first 
level three protocol port addresses, by sequencing 
through the structured routing device data to identify 
level three port addresses that are associated with a first 
level three protocol subnet and determining respective 
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first level three protocol subnet functions associated 
with such identified first level three protocol port 
addresses in the routed computer aetwork; and 

means for creating and storing first connection informa- 
tion in electronic memory indicating one or more 
associations between the first level three protocol sub- 
nets that have been identified and corresponding first 
level three protocol port addresses. 

34, An apparatus for analyzing a routed computer 
network, comprising: 

one or more processors; 

one or more storage devices that are accessible to the 
processors for storing data therein; 

one or more sequences of instructions stored in the one or 
more storage devices, which instructions, when 
executed by the one or more processors, cause the one 
or more processors to carry out the steps of: 

creating and storing structured routing device data in 
electronic memory which represents the routed com- 
puter network and in which stored level three protocol 
routing device port addresses Ve associated with cor- 
responding routing device names; 

identifying, based upon the structured routing device data, 
one or more first level three protocol subnets that are 
associated with corresponding first level three protocol 
port addresses, by sequencing through the structured 
routing device data to identify level three port 
addresses that are associated with a first level three 
protocol subnet and detennining respective first level 
three protocol subnet functions associated with such 
identified first level three protocol port addresses in the 
routed computer network; and creating and storing first 
connection information in electronic memory indicat- 
ing one or more associations between the first level 
three protocol subnets that have been identified and 
corresponding first level three protocol port addresses. 

* * * * * 
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